Non-null filtering, because sometimes insn's are null and transformer…

[Animowany]

… catches error.

[EpicPlayerA10]

If instruction is null then some transformer is badly designed. But if you really want, i've requested some small changes.

[EpicPlayerA10]

You don't need to check here if it is null as you already check it in FramedInstructionsTransformer

[EpicPlayerA10]

same here

[EpicPlayerA10]

same here

[EpicPlayerA10]

And for future reference, don't commit from a master branch, but create a new fresh branch for your PR. This will make it easier for you in your future PRs to any open-source repository.

[Animowany]

You wrote universalnumbertransformer, and i occured many nullpointers, so just inserted a check and now everything is fine.

[EpicPlayerA10]

You wrote universalnumbertransformer, and i occured many nullpointers, so just inserted a check and now everything is fine.

Hmm. That's unexpected behaviour. Maybe i do some sanity checks after each transformer if any transformer didn't accidentally break.

[Animowany]

You wrote universalnumbertransformer, and i occured many nullpointers, so just inserted a check and now everything is fine.

Hmm. That's unexpected behaviour. Maybe i do some sanity checks after each transformer if any transformer didn't accidentally break.

im now deobfuscating pretty heavily obfuscated jar, so maybe it has some as null presented insn's if its even possible

[EpicPlayerA10]

You wrote universalnumbertransformer, and i occured many nullpointers, so just inserted a check and now everything is fine.

Hmm. That's unexpected behaviour. Maybe i do some sanity checks after each transformer if any transformer didn't accidentally break.

im now deobfuscating pretty heavily obfuscated jar, so maybe it has some as null presented insn's if its even possible

If jar is valid and it is running well, then there shouldn't be any null instructions. Some transformer might broke it.

[Janmm14]

i never had to check an instruction being null with asm api except for getNext()/gtPrevious()

[narumii]

You wrote universalnumbertransformer, and i occured many nullpointers, so just inserted a check and now everything is fine.

Hmm. That's unexpected behaviour. Maybe i do some sanity checks after each transformer if any transformer didn't accidentally break.

im now deobfuscating pretty heavily obfuscated jar, so maybe it has some as null presented insn's if its even possible

If jar is valid and it is running well, then there shouldn't be any null instructions. Some transformer might broke it.

Perhaps better solution would be attaching the jar in question as a test suite?
Null insn should not happen, but at this point i would not be suprised since it is asm.

[EpicPlayerA10]

@Animowany Your issue should be partially resolved by 521c096 . Now the deobfuscator will throw an error which transformer did something bad in instructions list, instead of acting this weird behaviour with replacing all instructions with nulls. By this change you can then find the root cause of an error very easily.