- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
we should check every possible exception in a switch?
Admin
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?
Admin
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).
Admin
but if is very fast as it translates to a conditional jump in assembly. Exceptions are never this fast
Admin
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.
Admin
I see a business opportunity - new type of compilation optimizer which looks for idiotic code and optimizes it away.
Admin
Not sure if troll...
Because I couldn't believe that a TRWTF reader would actually be saying these words.
Admin
If you're going to do it, at least do it right: for...switch...every-conceivable-exception
Admin
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.
Admin
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.
Admin
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.
Admin
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); }
Admin
Hm, the format of the code came out differently than I expected it to be...
Admin
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.
Admin
The expensive part is creating the exception, not catching it.
Admin
this.setAttribute("Most Efficient and Complete!");
Admin
Right, and you don't want to have to create one of each exception type just to compare in the catch blocks
Admin
Someone is going to read this and invent an ExceptionEnum class to map a 2-byte binary map type to all possible exceptions.
Admin
Or better yet, the compiler itself modifies your source in such instances to fix the idiotic code! :D
Admin
I can not understand why there is no link close to the comment box that shows info on how to format text. WTF.
Admin
Why would you be trolling this sweet, quiet comment section? You monster
Admin
Sounds like the vigil programming language (https://github.com/munificent/vigil).
Admin
In convinced it's part of the joke that this site picks wtfy forum and comments packages.
Admin
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.
Admin
Explicit is better than implicit, and yet Python makes variable scope of all things implicit :(
Admin
No.
catchclauses do not trap exceptions in precedingcatchclauses, just in the main body of thetry. (Also, there's complication for exceptions thrown during thefinallyclause, but that's not your problem.)Also, your code had a pointless cast.
Admin
I've got some explicit language for this: @×$=@%■!!!
Admin
gcc -Oconsultant=highly-paid
Admin
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.)Admin
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...