• (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)
    Comment held for moderation.
  • (nodebb)
    try:
        match = None
        for item in items:
            if matches(item):
                match = item
                raise SystemExit("End loop")
    except BaseException:
        pass
    
  • (nodebb)
    Comment held for moderation.
  • ZZartin (unregistered) in reply to Nutster
    Comment held for moderation.
  • 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.

  • Creative Media News (unregistered)
    Comment held for moderation.
  • David Mårtensson (unregistered) in reply to The Beast in Black
    Comment held for moderation.
  • 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 #:

« Return to Article