• lolatu (unregistered) in reply to Tim
    Tim:
    hikari:
    My predecessor in my last job liked doing that sort of thing. But he did a lot of special things. Like throwing exceptions to break out of loops.

    Depending on the context, throwing an exception might just be the best way to break out of a loop. Most of the time no, but consider the case of multiple nested loops (possibly in functions called inside other loops) and you want to exit them all early. "break" will only break out of the inner-most loop. So you can have a flag that each loop checks on each iteration ... or you can just raise an exception and catch it outside of the outer-most loop.

    In some languages, exceptions are considered control flow e.g. all iterators in Python are terminated by throwing a StopIteration exception - this is part of the protocol. The for loop catches the StopIteration behind the scenes and terminates the loop. It's a very powerful technique that can make for much cleaner code.

    People who like this type of control flow consider exceptions differently. Using the for loop example:

    1. The normal case - there is another item to be returned from the iterator.

    2. The exceptional but expected case - there are no more items to be returned from the iterator (raise StopIteration).

    3. The error case - something happened that we didn't expect.

    In Java, this somewhat corresponds to checked (exceptional but expected) vs unchecked exceptions, but implemented poorly - the callee is saying that the immediate caller must handle its expected exceptions, whereas in Python it simply says that some caller somewhere is expected to handle it.

    php has the 'break #' syntax to specify how many levels deep you want to break out of. http://php.net/manual/en/control-structures.break.php

  • Tim (unregistered) in reply to lolatu
    lolatu:
    Tim:
    hikari:
    My predecessor in my last job liked doing that sort of thing. But he did a lot of special things. Like throwing exceptions to break out of loops.

    Depending on the context, throwing an exception might just be the best way to break out of a loop. Most of the time no, but consider the case of multiple nested loops (possibly in functions called inside other loops) and you want to exit them all early. "break" will only break out of the inner-most loop. So you can have a flag that each loop checks on each iteration ... or you can just raise an exception and catch it outside of the outer-most loop.

    ...

    php has the 'break #' syntax to specify how many levels deep you want to break out of. http://php.net/manual/en/control-structures.break.php

    Yes - and that's fragile. What happens when the code is refactored e.g. move the inner loop to another function? Better make sure you remember to update the number of loops you're breaking out of and/or check the return code of the new function ...

    Some languages have 'break label' syntax. That's better - and effectively it's a structured goto or like raising an exception and catching it at the label.

  • Goto (unregistered) in reply to Tim

    Or you could, you know, put the nested loops in a single function and return when you want to exit out of all of them. Or just use a goto, in one of the few situations when a goto is called for. It's certainly more clear than an exception, which could potentially send you anywhere in the program, or to a crash.

  • lolatu (unregistered) in reply to Tim
    Tim:
    lolatu:
    php has the 'break #' syntax to specify how many levels deep you want to break out of. http://php.net/manual/en/control-structures.break.php

    Yes - and that's fragile. What happens when the code is refactored e.g. move the inner loop to another function? Better make sure you remember to update the number of loops you're breaking out of and/or check the return code of the new function ...

    Some languages have 'break label' syntax. That's better - and effectively it's a structured goto or like raising an exception and catching it at the label.

    Agreed. I have never actually used the 'break #' syntax in practice. If I saw loops nested more than 3 deep I would probably be overcome by the code stench and refactor that mess.

  • Captain Oblivious (unregistered) in reply to chubertdev
    chubertdev:
    People who use exceptions for hack-ish control flow should be slapped around violently with a trout. The only time you raise in exception is when something wrong happens!

    Those are errors, a specific kind of exceptional case. There are other kinds of exceptional cases.

    exception (n): one that is excepted; especially : a case to which a rule does not apply

    error (n): an act that through ignorance, deficiency, or accident departs from or fails to achieve what should be done

    Exceptions are "exceptions" because the "rule" that defines the common case does not handle the exceptional case. Therefore, ad hoc control must be used to handle the exceptional case. Yes, you are writing ad hoc control/exception-handling code with your fancy OO patterns. (Factories are verbose functors. Command-interpreters are very verbose monads.)

  • Geoff (unregistered) in reply to lolatu
    lolatu:
    If I saw loops nested more than 3 deep I would probably be overcome by the code stench and refactor that mess.
    You clearly haven't done any scientific programming, where any half-decent function optimisation might take (quite) a few levels of looping. Just don't try it in Matlab if you can't vectorise the loops!
  • Fucked up email address specs? Blame Perl. (unregistered) in reply to Spewin Coffee
    Spewin Coffee:
    <...>

    And, within Perl modules, there are several TRWTFs like this gem:

    http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html

    Seriously? Why does "everybody" trot this out and claim that it proves Perl is (insert derogatory phrase here)? It seems like people copy and paste this tired piece of FUD because they say "Hurr! Durr! Lookit all teh charactres from the top of the keyboard! This sucks because there's no letters!". Am I missing something?

    1. This is a regular expression. This has nothing to do with Perl directly. You could create that monster in any language.

    2. This is part of the internals of a library - ordinary users will never need to fossic through this.

    3. This is the generated output of several variables that build the regex step-by-step from the RFC822 rules. The regex is not simply plopped down into the module like a steaming turd in a litter box. If you view the source of this module (https://metacpan.org/source/PDWARREN/Mail-RFC822-Address-0.3/Address.pm) you can see how it assembles the elements piece by piece from the grammar. (Only 62 lines of code - mostly variable assignments).

    4. The grammar for RFC822 is absolutely nasty (Line wrapping? Comments in the middle of an address?! WTF?!). You will need a complex set of rules to accurately describe all the possibilities and corner cases while catching invalid strings. ".+@.+" ain't gonna cut it.

    I need a drink...

  • wtf it's friday (unregistered) in reply to hikari
    hikari:
    ... But he did a lot of special things. Like throwing exceptions to break out of loops.

    http://docs.python.org/2/library/exceptions.html#exceptions.StopIteration

  • gnasher729 (unregistered) in reply to Tim
    Tim:
    Depending on the context, throwing an exception might just be the best way to break out of a loop. Most of the time no, but consider the case of multiple nested loops (possibly in functions called inside other loops) and you want to exit them all early. "break" will only break out of the inner-most loop. So you can have a flag that each loop checks on each iteration ... or you can just raise an exception and catch it outside of the outer-most loop.

    In some languages, exceptions are considered control flow e.g. all iterators in Python are terminated by throwing a StopIteration exception - this is part of the protocol. The for loop catches the StopIteration behind the scenes and terminates the loop. It's a very powerful technique that can make for much cleaner code.

    For the growing number of Objective-C developers, an exception is assumed to be a programming error. You are not supposed to handle exceptions, but exit the program as gently as you can (there are very few exceptions to this rule), and then go and fix the bug in your code. Fun when Java code gets ported to Objective-C :-(

  • jay (unregistered) in reply to chubertdev
    chubertdev:
    People who use exceptions for hack-ish control flow should be slapped around violently with a trout. The only time you raise in exception is when something wrong happens!

    A sufficiently determined programmer can write a Fortran program in any language. Exceptions let you simulate GOTO's in languages that thought they didn't have GOTO's.

  • (cs) in reply to Captain Oblivious
    Captain Oblivious:
    chubertdev:
    People who use exceptions for hack-ish control flow should be slapped around violently with a trout. The only time you raise in exception is when something wrong happens!

    Those are errors, a specific kind of exceptional case. There are other kinds of exceptional cases.

    exception (n): one that is excepted; especially : a case to which a rule does not apply

    error (n): an act that through ignorance, deficiency, or accident departs from or fails to achieve what should be done

    Exceptions are "exceptions" because the "rule" that defines the common case does not handle the exceptional case. Therefore, ad hoc control must be used to handle the exceptional case. Yes, you are writing ad hoc control/exception-handling code with your fancy OO patterns. (Factories are verbose functors. Command-interpreters are very verbose monads.)

    I don't have a lot of confidence in people that use Merriam-Webster's definitions of technical terms to determine their development usage.

  • PRMan (unregistered) in reply to Krunt
    Krunt:
    Wody:
    Although the method used is a wtf, getting dates from the database (possibly running on another computer) instead of the local computer isn't a wtf at all.

    Dates is more than just a day, it involves the time as well, and guarantees the same dates are used, which is important for operations involving computers in different timezones. The client should do math on dates, but only to convert the standard timezone, to a user-friendly-date/time and it should show the database-data as well when needed.

    It also can be used to test the database-connection without involving important data, and bothering users while entering this important data in the database.

    Good God, please be joking about everything you just said. Please.

    Not necessarily. I worked at one place where we were to get all dates from the SQL Server so that everything on different machines would sync properly.

    Of course, I suggested that they institute NTP on all the servers, but that was pretty new in 1991.

  • Captain Oblivious (unregistered) in reply to chubertdev
    chubertdev:
    Captain Oblivious:
    chubertdev:
    People who use exceptions for hack-ish control flow should be slapped around violently with a trout. The only time you raise in exception is when something wrong happens!

    Those are errors, a specific kind of exceptional case. There are other kinds of exceptional cases.

    exception (n): one that is excepted; especially : a case to which a rule does not apply

    error (n): an act that through ignorance, deficiency, or accident departs from or fails to achieve what should be done

    Exceptions are "exceptions" because the "rule" that defines the common case does not handle the exceptional case. Therefore, ad hoc control must be used to handle the exceptional case. Yes, you are writing ad hoc control/exception-handling code with your fancy OO patterns. (Factories are verbose functors. Command-interpreters are very verbose monads.)

    I don't have a lot of confidence in people that use Merriam-Webster's definitions of technical terms to determine their development usage.

    The point is that there is no semantic difference between handling exceptional cases and ad hoc flow control. Merriam-Webster doesn't enter into that point. You would not need any ad hoc flow control -- at all -- if all the cases could be handled uniformly. If the cases cannot be handled uniformly, you absolutely need to distinguish between the cases. This is typically called "throwing" an exception.

  • IN-HOUSE-CHAMP (unregistered)

    what kind of "senior" developer admits to being wrong?

  • Krunt (unregistered) in reply to PRMan
    PRMan:
    Krunt:

    Good God, please be joking about everything you just said. Please.

    Not necessarily. I worked at one place where we were to get all dates from the SQL Server so that everything on different machines would sync properly.

    Of course, I suggested that they institute NTP on all the servers, but that was pretty new in 1991.

    That doesn't make it right. There is a reason UTC exists.

  • Krunt (unregistered) in reply to Captain Oblivious
    Captain Oblivious:
    The point is that there is no semantic difference between handling exceptional cases and ad hoc flow control. Merriam-Webster doesn't enter into that point. You would not need any ad hoc flow control -- at all -- if all the cases could be handled uniformly. If the cases cannot be handled uniformly, you absolutely need to distinguish between the cases. This is typically called "throwing" an exception.

    I'm not sure what language you're using, but I know that in .NET at least exceptions were always expensive to throw due to instrumented logging and it's long since been an accepted best practice to NEVER use them for control flow. This may be different for Java, but exceptions in .NET always mean something bad has happened - not "I just need to step out of this loop".

    Also, TRWTF is burying yourself many layers deep in loops. There's always a better way. Refactor that mess.

  • (cs) in reply to Krunt
    Krunt:
    I'm not sure what language you're using, but I know that in .NET at least exceptions were always expensive to throw due to instrumented logging and it's long since been an accepted best practice to NEVER use them for control flow. This may be different for Java, but exceptions in .NET always mean something bad has happened - not "I just need to step out of this loop".

    Also, TRWTF is burying yourself many layers deep in loops. There's always a better way. Refactor that mess.

    +1

    http://msdn.microsoft.com/en-us/library/ms229009.aspx

  • OnceUponASpace (unregistered) in reply to Spewin Coffee

    Ok so I'm no great fan of perl, but seriously, can't you read dude?

    "...provides the same functionality as RFC::RFC822::Address, but uses Perl regular expressions rather that the Parse::RecDescent parser. This means that the module is much faster to load as it does not need to compile the grammar on startup...

    ...The regular expression below shows the complexity, although its inclusion on this page has caused some confusion:

    • I did NOT write this regular expression by hand. It is generated by the Perl module by concatenating a simpler set of regular expressions that relate directly to the grammar defined in the RFC."

    If you look at the actual source it's 120 lines of pretty straightforward code (assuming you're familiar with regex) that does the same thing that Parse::RecDescent would do, only slightly more compressed using small, clean regex.

    Care to explain why this is the "wrong solution"?

    Given that the guy was unhappy with aspects of the performance of the the standard perl BNF parser version, what's your preferred solution? I suppose in your world you think he should have spent a week hand-rolling something C-based via XS etc.

    Sigh. This site really sucks, it's like some kind of honeypot for programmers with a serious case of Dunning-Kruger effect.

    There are more meta-wtfs where the wtf is the wtf on this site than there are actual underlying wtfs.

    I'm outta here lusers. Smell ya later.

    "Once there was a programmer who had a string manipulation problem the complexity of which was greater than could be reasonably solved with standard substr/instr operations, but which didn't really warrant the implementation or use of a full blown BNF-parser. He could have used a one-line regex. Then he would have had a solution, and the subsequent standard maintenance problems that come with adding any code. Instead he had read cutesy folk-wisdom on the interwebs that told him "regex are bad, and simply shouldn't exist". So he implemented his own slow, poorly-designed, badly-implemented and buggy tokenising/lexing finite state-machine instead. He now had a metric f*ck-ton of problems."

  • Neil (unregistered) in reply to gnasher729
    gnasher729:
    You are not supposed to handle exceptions, but exit the program as gently as you can (there are very few exceptions to this rule)
    I heard you like exceptions, so I made some exceptions to your exceptions...
  • Matt Quinn (unregistered) in reply to Krunt

    Hahah - my thoughts exactly!

Leave a comment on “You Can't Spell "Date" Without "Database"”

Log In or post as a guest

Replying to comment #:

« Return to Article