- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- 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
I was so tempted to not respond and leave the comment counter at zero...
Admin
Seriously, WTF??
I suspect that codebase could keep the site going for months.
Admin
And that's a bank-to-bank transaction, if I'm not mistaken. I'm going to withdraw my money now, and store it in an old sock, where Nasch' friends have no power.
Admin
Handling exceptions by dividing by zero? Hilarious :D
And outrageous. If you see that in your codebase, immediately call an exorcist!
Admin
Is this a creative way to log the stack trace?
Admin
I prefer to use out of memory exceptions for control flow.
Admin
That could work for an interpreted language, but in a compiled language, the optimizer will see the calculation is never assigned nor has a side effect, so will throw it away. Mind you, it may report the constant divisor of 0 as an error and stop before it gets to the optimizer.
Admin
It absolutely does have an observable side effect: it's required by the language spec to throw a DivideByZeroException! So the compiler isn't allowed to optimize it away.
Admin
Sxith?
Admin
You only need to call the exorcist when you get to the exception handler that does 666/0
Admin
So a couple of things. One, this pattern isn't all over the code base, I think it's in three or four spots. Second, the braces around the if are not there in the original, so the only statement that executes when the if evaluates to true is 6/0.
Admin
This reminds me a little bit of a coworker I had who would write methods with a return type of exception. If they returned nothing, they had succeeded. This actually warps my brain less.
I sometimes wonder if he did that to poke fun at his own reputation for being pessimistic.
Admin
This is actually fairly common in the Go world. It is quite common for Go functions (including in Go's standard library) to return just an
error
value. Such functions will returnnil
if there were no errors, or an actual error if there was one. Your coworker was ahead of his time :)Admin
It's worse - it's creating an exception to handle when you don't even need one. If I'm reading it right everything in the catch block could be moved into the if processing and it would work the same. Except without the overhead of exception handling.
This isn't the most egregious use of exception handling where it isn't needed that I've ever seen (that was throwing and catching an exception to terminate a loop) but it's pretty close. Yeesh.
Admin
According to nasch, it wouldn't: there is a lot of stuff between actual
if
andcatch
(lost in anonymization). But an early return could do the trick... of course that would violate the "single exit point" policy.How weird. I'd use
goto
.Admin
Admin
"single exit point rule" is an antipattern
Admin
I think it comes from C, where single-point-of-exit helps to avoid forgetting to free resources during an early exit. And probably also more relevant when taking into account repeated changes to a functions implementation during maintenance and future extensions, than during initial writing, where the programmer is more likely to have a complete overview of what to cleanup when.
Applied to a language with more structured ways of resource- and error-handling though? Antipattern I'd say.
All hail
#define ZERO 0
. Or Britannia, or whatever.Admin
Single point of exit comes from Fortran IV, where you can enter a function at multiple points and return from it TO multiple points in the caller.