• bvs23bkv33 (unregistered)

    we should check every possible exception in a switch?

  • Jaloopa (unregistered)

    Seems perfectly sensible to me. Exception handling is expensive as we all know. Each catch adds to that expense so why not combine it all in one catch and sort from there?

  • Pjrz (unregistered) in reply to Jaloopa

    Exception handling may be more expensive than no exception handling. But if you have it, then my guess is there is going to be little difference having multiple catches and a single catch with multiple 'ifs' (it's even conceivable that would be preventing certain compiler optimisations).

  • Jaloopa (unregistered) in reply to Pjrz

    but if is very fast as it translates to a conditional jump in assembly. Exceptions are never this fast

  • David Mårtensson (unregistered) in reply to Jaloopa

    No, but if you use multiple catch with different exception types I bet its implemented as a series of jmp_if ops in the compiled code so the original catching of the exception is expensive but using multiple catch probably add almost no extra overhead after the first.

  • (nodebb)

    I see a business opportunity - new type of compilation optimizer which looks for idiotic code and optimizes it away.

  • Debra (unregistered) in reply to Jaloopa

    Not sure if troll...

    Because I couldn't believe that a TRWTF reader would actually be saying these words.

  • snoofle (unregistered) in reply to bvs23bkv33

    If you're going to do it, at least do it right: for...switch...every-conceivable-exception

  • Raj (unregistered) in reply to Debra

    True. The proper way to do it would be to encapsulate each branch of that switch in a distinct method so they can be unit tested.

  • Jaloopa (unregistered) in reply to Raj

    That's a good point. You'd want your own subclass of Exception that lets you implement an IException interface for proper mocking in the tests.

  • Nik (unregistered)

    There are legitimate reasons to have instanceof checks in Java catch blocks and the snippet is too redacted to judge whether it was one of those.

    A very typical example: try { } catch (MyException e) { throw (MyException) e; } catch (Exception e) { throw new MyException(e); }

    This does not what you expect it to do: Every exception - even MyExceptions - will be wrapped in a new MyException. That is because the second catch block will receive all Exceptions thrown in the first block. Such a construct can only be done with instanceof checks.

  • Lothar (unregistered)

    There are valid cases where you do something like this, e.g. if you want to avoid code duplication:

    try { reserveResourcesThatAreRequiredLater(); } catch(Exception e) { // release not possible in finally, because we intended to work with these resources later releaseResources(); doSomeLogging(e); if (e instanceof SpecialCaseException) { releaseSomethingSpecial(); } if (e instanceof SomethingHappenedException) { throw (SomethingHappenedException) e; } throw new SomethingHappenedException("something bad has happened", e); }

  • Lothar (unregistered) in reply to Lothar

    Hm, the format of the code came out differently than I expected it to be...

  • (nodebb) in reply to Mr. TA

    I see a business opportunity - new type of compilation optimizer which looks for idiotic code and optimizes it away.

    I don't think I'd find many people here objecting to an assertion that UB is idiotic code, and apparently later versions of clang do, indeed, make optimisations on the basis that code elsewhere will not invoke UB here.

  • Kleyguerth (github) in reply to Jaloopa

    The expensive part is creating the exception, not catching it.

  • (nodebb) in reply to snoofle

    If you're going to do it, at least do it right: for...switch...every-conceivable-exception

    this.setAttribute("Most Efficient and Complete!");

  • Jaloopa (unregistered) in reply to Kleyguerth

    Right, and you don't want to have to create one of each exception type just to compare in the catch blocks

  • (nodebb) in reply to Jaloopa

    Right, and you don't want to have to create one of each exception type just to compare in the catch blocks

    Someone is going to read this and invent an ExceptionEnum class to map a 2-byte binary map type to all possible exceptions.

  • Winston (unregistered) in reply to Mr. TA

    Or better yet, the compiler itself modifies your source in such instances to fix the idiotic code! :D

  • King (unregistered) in reply to Lothar

    I can not understand why there is no link close to the comment box that shows info on how to format text. WTF.

  • Supersonic Tumbleweed (unregistered) in reply to Jaloopa

    Why would you be trolling this sweet, quiet comment section? You monster

  • Karl Bielefeldt (github) in reply to Mr. TA

    Sounds like the vigil programming language (https://github.com/munificent/vigil).

  • Dave (unregistered) in reply to King

    In convinced it's part of the joke that this site picks wtfy forum and comments packages.

  • (nodebb)

    Throwing exceptions as part of normal flow of code is terribly slow... as least in some platforms. I can't imagine Java to be better (than anything else, really).

    Having a conditional check and code branch from there would be A LOT faster.

  • Klaus (unregistered)

    Explicit is better than implicit, and yet Python makes variable scope of all things implicit :(

  • (nodebb) in reply to Nik

    Every exception - even MyExceptions - will be wrapped in a new MyException.

    No. catch clauses do not trap exceptions in preceding catch clauses, just in the main body of the try. (Also, there's complication for exceptions thrown during the finally clause, but that's not your problem.)

    Also, your code had a pointless cast.

  • (nodebb)

    I've got some explicit language for this: @×$=@%■!!!

  • ChoHag (unregistered) in reply to Mr. TA

    I see a business opportunity - new type of compilation optimizer which looks for idiotic code and optimizes it away.

    gcc -Oconsultant=highly-paid

  • (nodebb)

    Maybe they were used to JavaScript which doesn't have conditional exception handling? (Some old versions of SpiderMonkey support catch (e if <cond>) but it's since been removed because it's non-standard.)

  • owlstead (unregistered)

    Weird. I still see a lot of "but the other thing is faster" comments here. This code runs inside a catch block, so you already have an exception, so unless you're relying on exception handling in your code, the efficiency is really of secondary concern.

    With Java's catch and multi-catch, it is of course still pretty stupid and error prone code, because it would be extremely easy to miss an exception this way, the code is hard to read, hard to test, etc.

    That said, it probably runs OK, so it's not a huge CodeSOD...

  • SicfpThedy (unregistered)
    Comment held for moderation.
  • HdcffThedy (unregistered)
    Comment held for moderation.
  • SicfpThedy (unregistered)
    Comment held for moderation.
  • Gtcismves (unregistered)
    Comment held for moderation.
  • Wtcissves (unregistered)
    Comment held for moderation.
  • Gtcismves (unregistered)
    Comment held for moderation.
  • SicfpThedy (unregistered)
    Comment held for moderation.
  • Tecihnves (unregistered)
    Comment held for moderation.
  • Sdvillsof (unregistered)
    Comment held for moderation.
  • Sdvillsof (unregistered)
    Comment held for moderation.
  • Sdvillsof (unregistered)
    Comment held for moderation.
  • Sdvillsof (unregistered)
    Comment held for moderation.

Leave a comment on “Conditionally Exceptional”

Log In or post as a guest

Replying to comment #503509:

« Return to Article