• (nodebb)

    I was so tempted to not respond and leave the comment counter at zero...

  • FTB (unregistered)

    Seriously, WTF??

    I suspect that codebase could keep the site going for months.

  • Hanzito (unregistered)

    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.

  • Sauron (unregistered)

    Handling exceptions by dividing by zero? Hilarious :D

    And outrageous. If you see that in your codebase, immediately call an exorcist!

  • nz (unregistered)

    Is this a creative way to log the stack trace?

  • OOM (unregistered)

    I prefer to use out of memory exceptions for control flow.

  • (nodebb)

    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.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered) in reply to Nutster

    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.

  • Sole Purpose Of Visit (unregistered)

    Sxith?

  • (nodebb) in reply to Sauron

    You only need to call the exorcist when you get to the exception handler that does 666/0

  • nasch (unregistered)

    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.

  • (nodebb)

    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.

  • (nodebb) in reply to kilroo

    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 return nil if there were no errors, or an actual error if there was one. Your coworker was ahead of his time :)

  • (nodebb) in reply to Sauron

    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.

  • nz (unregistered) in reply to Jer

    According to nasch, it wouldn't: there is a lot of stuff between actual if and catch (lost in anonymization). But an early return could do the trick... of course that would violate the "single exit point" policy.

    throwing and catching an exception to terminate a loop

    How weird. I'd use goto.

  • löchlein deluxe (unregistered)

    I will raise my hand and admit I've done something like that… in a mandatory fun day assembler class in Freshuman year. Hell no am I going to go find out how to set flags for arithmetic exceptions in my implementation of … sqrt maybe? in 68k assembler when I can just divide something by zero and have the computer do it for me.

  • (nodebb) 
    try:
    match = None
    for item in items:
        if matches(item):
            match = item
            raise SystemExit("End loop")
except BaseException:
    pass
  • (nodebb)

    A Pascal codebase was translated from Unix to IBM Mainframe. The goal was to make a single codebase run on both systems, without pandering to either one. Exceptions, error handling, and system abort / exit were especially troublesome to translate.

    The generic abort function emitted the given error message, then divided by zero. Except in IBM land, that was just a warning, and execution continues at the next step. Sort of "Try, don't catch, and pretend nothing happened".

  • ZZartin (unregistered) in reply to Nutster

    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.

    Oh there's a real easy way to get around that.

    Integer a = 0; Integer b = 6 / a;

  • kolik (unregistered) in reply to nz

    "single exit point rule" is an antipattern

  • (nodebb) in reply to kolik

    "single exit point rule" is an antipattern

    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.

  • (nodebb) in reply to R3D3

    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.

  • David Mårtensson (unregistered) in reply to The Beast in Black

    That pattern is common in at least older C code where exceptions did not exist in that manner.

    So you returned an integer and if it was 0 everything is OK, and if not you have an error.

    The calling code could then be

    if(DoSomething()) { We got an error }

    since 0 counts as false.

    I would generally consider this to be bad for any language with real exception handling.

    If you expect the exception to be common enough that you want to avoid the overhead of gathering stacktrace and everyting, you should not consider it an error state but just a state to be handled.

  • MemeShell (unregistered)

    I once had to use BeanShell to dynamically load some short Java code, it wouldn't print from it, and throwing exceptions manually I think wouldn't work either, so I resorted to Integer.parseInt(myLogString);. It did throw that one.

    Fortunately I only had to use it once or twice until we convinced the client to just have that code not be user given but inside the project.

Leave a comment on “An Exceptional Zero”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article