71

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

Comments
  • 7
    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.
  • 10
    // TODO: todo
    catch(NullPointerException e) {
    throw new NullPointerException();
    }
  • 4
    @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"
  • 8
    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.
  • 2
    @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?).
  • 0
    @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.
  • 1
    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
  • 3
    @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.
  • 0
    @Pickman as far as iknow a try catch would be a more expensive operation than an if
  • 0
    @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).
  • 1
    LOOK AT THE SHIT HE DID HERE 😡
Add Comment