Catching a NullPointerException so that it can cause another NullPointerException to the caller. 🤯

No you just mask OMG EMERGENCY EVERYTHING IS BROKEN into a harmless "welp, there's nothing" which you can check with a simple fucken if.

// TODO: todo
catch(NullPointerException e) {
throw new NullPointerException();
}

@IAmAnIssue this one has it own special circle of hell. bc it ignorea the original exception, and generating a new one with no details of what went wrong...

And returning null could in theory be ok for the OP. "tried to io, but failed boss. here is a null - bc you don't want to crash, or handle my shit"

Pfff....
Special circle of Hell... Amateurs.

Try this one:

catch(Exception e) {}

I found it in production. After 6 hours of debugging. The application simply wasn't working. This one creates a circle of hell directly here on Earth.

@nitwhiz probably not a brilliant idea however. A catch is not more complicate than an if after all and it could be more expressive potentially (e.g. return a.getB(); returns null. Is a or b the null object?).

@Pickman Thats just your regular hell circle - standard lava, regular demon, ordinary pitchforks. Nothing special about it.
I have some regexs to search through the code base looking for this, when I was doing Java refactors long long time ago. this one would escape that filter....

The one I refered to deserves a special hell circle - bc he is doing something with the exception caught. Just nothing usefull, or even logging it.... this deserves the extra hot lava with cobalt64 added, the 7 point pitchforks, and the extra nasty demons. Oh - and a special ice bath.

Most often I just use
catch (Exception e) { e.printStackTrace(); }
when the IDE stubbornly keeps telling me that something can produce some exception even though it is surrounded by try-catch

@magicMirror dude, it's regular hell only if your codebase is small and does not use reflection. It's special hell once the IDE creates a //TODO for you and you delete it.

@Pickman as far as iknow a try catch would be a more expensive operation than an if

@techno848 not necessarily. Try catch means that the instruction is immediately handled. Throw means that you have to unwind the stack and that could take a while. However if you do not have finally blocks eventually you woul gave to unwind that stack anyway so it does not cost more than a normal execution with if instead of a throw.
If you throw something and it runs through half the stack it's likely that you're overcomplicating things anyway.
You know what is the real cost in Java? Function calls.
How I see it if you can treat a case with an if go for it... But if you need to pass information on something to the caller consider a throw because it does not constraint your design (and possibly force you to write inefficient code).

LOOK AT THE SHIT HE DID HERE 😡