Construct I haven't seen in a long time



  • Pseudo code:

     

    while (true) {
    try {
    L0: Message msg = queue.take(); // non-blocking read
    MessageTypeEnum mte = // figure out what type of message was received
    switch (mte.getNumericValue()) {
    case 1: { L1: // do stuff
    break L1;
    }
    case 2: { L2: // do stuff
    break L2;
    }
    ...
    case 14: { L14: // do stuff
    break L14;
    }
    default: { L15: // do stuff
    break L15;
    }
    }
    } catch (Exception e) {
    // ...
    }
    }



  • Named breaks, those are unusual indeed.



  • I didn't know you could perform a named break to a label within the same scope as the break statement itself - wouldn't those effectively behave as goto statements?



  • You can in actionscript.



  • I thought the WTF was not checking if the non-blocking read failed (returned null). Am I now the WTF or was that part of the WTF?



  • @henke37 said:

    You can in actionscript.

    Or JavaScript, on which ActionScript is based.



  • I didn't know that javascript has try blocks.



  • @henke37 said:

    I didn't know that javascript has try blocks.

    Brave of you to share your personal failings with the group.



  • @blakeyrat said:

    @henke37 said:
    I didn't know that javascript has try blocks.

    Brave of you to share your personal failings with the group.

     

    Man, speaking of personal failings, why have I just now realized my sentiments about try/catch are actually summed up by "Do! Or, do not. There is no try."

     

    (More seriously, and less sad all around, is that I really have a conceptual problem with the concept of try... it's like you're coding but you don't know why something could go wrong, so you don't check your inputs and just let the downstream guy try it and you just stand there holding a barf bag to catch the refuse later.  I think maybe it's just the words they used ... "try" and "catch" that bug me.  I actually do understand the merits of having a system that can bail out from deep within a call stack instead of every function having to check return values all the way back up.  But it seems like most people don't use it that way but instead use it as a catch-all as described above.

    Heh - I just realized that try and catch are fancy versions of setjmp and longjmp.  Commence the refutation and wailing! )



  • Yeah, I should definitely check whether I have permissions to a directory, whether the disk has space, etc. before trying to write to a file.



  • @too_many_usernames said:

    ...it's like you're coding but you don't know why something could go wrong, so you don't check your inputs and just let the downstream guy try it and you just stand there holding a barf bag to catch the refuse later...

    ...But it seems like most people don't use it that way but instead use it as a catch-all as described above...
    There are all kinds of situations in which you don't know why something could go wrong - pretty much anything which involves dealing with hardware, for a start. Take reading from a stream - in principle you don't even know what's on the other end. It could be a process writing to a pipe which gets killed halfway through a message. It could be a host sending network packets which reaches a timeout. It could be ... etc. But yes, handling exceptions in the right place requires more thought than some people are willing to realise or to apply.


  • @Sutherlands said:

    Yeah, I should definitely check whether I have permissions to a directory, whether the disk has space, etc. before trying to write to a file.

     

    Actually, perhaps you should.  In many arenas it's much safer to see if you could do something before attempting it, because the attempt can be more damaging than doing nothing at all.

    I'm almost willing to wager one Internet that many vulnerabilities arise because people attempt to perform some operation before determining if it should be attempted.  I wonder if it could be considered a class of uninitialized variable error.

     



  • @too_many_usernames said:

    @Sutherlands said:

    Yeah, I should definitely check whether I have permissions to a directory, whether the disk has space, etc. before trying to write to a file.

     

    Actually, perhaps you should.  In many arenas it's much safer to see if you could do something before attempting it, because the attempt can be more damaging than doing nothing at all.

    I'm almost willing to wager one Internet that many vulnerabilities arise because people attempt to perform some operation before determining if it should be attempted.  I wonder if it could be considered a class of uninitialized variable error.

    too_many_usernames: make sure you check all your inputs!

    Sutherlands: because the disk being full is something I should definitely check

    too_many_usernames: you should!

     

    :roll:

     

    Ok, kids, here's the new paradigm:

    while(bytesToWrite)
    {

       if(HasPermissions() && !DiskIsFull())

          WriteByte(fileStream);

    }

     

    Oh wait, we still have race conditions!  Dang, looks like we'll have to stick with those crappy try/catch things.  Wait, they're fancy versions of setjmp and longjmp?  Well... I suppose they do something similar... but they do a LOT more than those.  I mean, like, a LOT more than comparing a switch to a bunch of gotos.

     

    You need to check your inputs before calling a method almost always.  But there are some things that you can't detect, like... a stream terminating abruptly in the middle of a send.


  • Trolleybus Mechanic

    @Some Really Fucked Up Pseudocode said:

    HttpWebRequest throws WebRequestException

    So before I make a web call I should make sure I can make the web call?



  • @Sutherlands said:

    But there are some things that you can't detect, like... a stream terminating abruptly in the middle of a send.

    I think for the most part we're just missing something in translation... but the above statement has me confused: why can't you detect a stream terminating abruptly in the middle of the send?

    @Lorne Kates said:

    So before I make a web call I should make sure I can make the web call?

    Of course! Then you should make sure that you can make the call to make sure you can make the call to make the web call. It helps if you have turtles*, of course.

    *If I have to explain why turtles would be useful in this situation...



  • Exceptions are intended for EXCEPTIONAL conditions. If you can check for it, you should. As I have posted before...work just once on a project that will cause your cell phone to ring everytime an exception is thrown (even if it is immediately caught) and you will get in the habit quickly.

    edit: and when the cell phone rings, you have to dial into the system, find out the cause, and log it before production is allowed to continue. Downtime is directly "deducted" from your review score.



  • @TheCPUWizard said:

    Exceptions are intended for EXCEPTIONAL conditions.

    The disk being full IS an exceptional condition. So is your program not having permission to write to a directory it needs to write to. These are things that only happen when something is seriously wrong and your entire program is about to crash horribly! What the hell are you going to do after checking for them that would not be functionally equivalent to just letting the language raise an exception anyway?

    (Also, the argument from etymology is a logical fallacy. There are plenty of perfectly good, efficient, maintainable idioms that use "exceptions" in non-exceptional circumstances. Check out the standard library of your language of choice and be amazed at the things they are useful for!)

    @TheCPUWizard said:

    As I have posted before...work just once on a project that will cause your cell phone to ring everytime an exception is thrown (even if it is immediately caught) and you will get in the habit quickly.
    I would immediately quit any job that tried to bring in a bullshit rule like that.  Cargo-cult nonsense like "our code must never throw any exceptions!!!!!" does not sound engineering practice make.

     



  • @too_many_usernames said:

    I'm almost willing to wager one Internet that many vulnerabilities arise because people attempt to perform some operation before determining if it should be attempted.  I wonder if it could be considered a class of uninitialized variablesystem error.

    FTFY.



  • @too_many_usernames said:

    But it seems like most people don't use it that way but instead use it as a catch-all as described above.

    I think that's the main point.

    If you're doing this:

    
    Try
    {
        //anything
    }
    Catch(Exception e){}
    
    

    You're probably doing something wrong.

    Obviously anything you know might go wrong should probably be checked for beforehand, but there are many circumstances (as others have noted) where you just don't know what could possibly go wrong.

    Three words: third party tools.

    Also, in some instances it's faster/easier/clearer to just try to do something and deal with the potential consequences in the catch block instead of trying to validate every input and/or think of every possible way the input could be bad. E.g. is it better to have 50 lines of code checking inputs for every exception case, or ~5 lines of code for a try/catch and just log any error that comes through? I suppose it depends on the circumstances, but most of the time you probably wont need the granularity that those 50 lines give you.



  • @AerieC said:

    You're probably doing something wrong.

    Obviously anything you know might go wrong should probably be checked for beforehand, but there are many circumstances (as others have noted) where you just don't know what could possibly go wrong.

    Three words: third party tools.

    Also, in some instances it's faster/easier/clearer to just try to do something and deal with the potential consequences in the catch block instead of trying to validate every input and/or think of every possible way the input could be bad. E.g. is it better to have 50 lines of code checking inputs for every exception case, or ~5 lines of code for a try/catch and just log any error that comes through? I suppose it depends on the circumstances, but most of the time you probably wont need the granularity that those 50 lines give you.

    Speaking of which, I'd like to invite you all to [url=http://forums.thedailywtf.com/forums/t/25228.aspx]a little thread I made the other day[/url] about a third-party method which would fulfill that very scenario.


Log in to reply