• (nodebb)

    it just eradicated the error message anyway

    Isn't this RTWTF, when combined with "using the error message to determine what happened"?

  • Prime Mover (unregistered)

    I myself just today have looked at the general design of a package, hated what I've seen, would have loved to have changed it, but was instructed to use the existing paradigm or it might cause breakage downstream.

    Hence I was required to contribute to, and further propagate, the continuing stupidity when I really would have preferred not to.

    Sympathies with Raquel's coworker.

  • (nodebb)

    But the block also gets weird- why is there a case where SomeInternalException gets wrapped in a new instance of SomeInternalException with the same message?

    I expect that somebody somewhere had some code like:

    Throwable cause = thrownException.getCause();
doSomethingWithCauseExpectingItToBeNonNull(cause);

    And they couldn't be bothered to put the null test in.

  • (nodebb)

    Unfortunately, if you ever deal with JDBC directly then you're probably going to end up with something almost as nasty as this; DB drivers aren't usually very good at making it easy to take advantage of the exception type system.

    But wrapping an exception in another exception of the same type is a WTF all of its own. Just no. Excessive exception wrapping is a minor antipattern.

  • (nodebb) in reply to Prime Mover

    And there are those days where you don't have the energy to hunt down the 30 places that this code matters, and handle them. So you make your edits, check them in... and the next time you're looking at this particular code, you don't have the energy to hunt down the 50 places this code matters...

  • NotAThingThatHappens (unregistered) in reply to Jeremy Pereira

    If they wouldn't, the exception would be converted into a 'GenericStorageException'. Which may have not been desirable.

    Personally, I am not a fan of this kind of 'Pokemon exception handling'. Most exceptions boil down to 'Something went wrong, try again' and 'Something is broken, it will never work'. Since contacting a Redis is unlikely to brick your database, you can just do a retry, if it fails again it's the second kind of exception, and then just let the application fail with the native exception. which is likely to generate more hits when you search the internet for documentation (that your in house exception).

    But hey, that's just me.

  • Prime Mover (unregistered) in reply to PotatoEngineer

    In such cases you consider adding a comment into the code you're checking in:

    "I haven't got the spoons."

  • Stack Trace { (unregistered)

    "But the block also gets weird- why is there a case where SomeInternalException gets wrapped in a new instance of SomeInternalException with the same message?"

    This is a result of "An error is ok but you absolutely mustn't not shown the technicalities of our software's (non-)technical stack elements in the error message!" It may be a design thing, it may be the "lead developer's" prettiness constraints (have you ever looked at he ZRAM init scripts? zomfg), it may be .... who knows.

  • (nodebb) in reply to Stack Trace {

    It's indeed not a good idea to show stack traces to ordinary users (especially if they're from deep inside a heavily frameworked application!) as there is literally nothing they can do about them except worry uselessly, but the point to take care of that is when the exceptions are converted into error messages or logging events. Wrapping exceptions inside more exceptions doesn't help with that.

  • WTFGuy (unregistered)
    Comment held for moderation.

Leave a comment on “Inner Exceptions”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article