Exception handling is hard



  • Found this today in a legacy application (where else?)

        else {
                throw new Exception("Error in file " + filename);
        }
    }
    catch (Exception ex) {
                throw ex;
    }
    

    If I had the power to do so, I would find the original developer, fire him, re-hire him and then immediately fire him again.

    EDIT: Corrected the code. "throw new ex" is not valid C#.


  • Winner of the 2016 Presidential Election

    @Hans_Mueller said in Exception handling is hard:

    throw new ex

    The thought does cross your mind when they're newly ex, doesn't it?


  • sockdevs

    @Hans_Mueller Is that Java? Because it's not valid C#:
    0_1490197191881_upload-c7097eff-2b09-4878-902c-fdbf0879b030


  • Winner of the 2016 Presidential Election

    @RaceProUK I was wondering if there was a C# feature I was unaware of.

    Also, that brace/indent style hurts my eyes


  • sockdevs

    @Jaloopa said in Exception handling is hard:

    Also, that brace/indent style hurts my eyes

    His or mine?


  • Winner of the 2016 Presidential Election

    @RaceProUK His. I approve of your style



  • @Jaloopa Well, he seems to indent way too much, but the braces are ok.



  • @Jaloopa said in Exception handling is hard:

    I approve of your style

    That's what happen when you're paid by line of code :wink:


  • area_deu

    @Khudzlin said in Exception handling is hard:

    but the braces are ok.

    else without a leading one?

    Which might imply

    if (condition) {
        // Do stuff
    }
    else {
       // Do stuff
    }
    

    ?

    No, this feels wrong.



  • @aliceif What's wrong about it?


  • Winner of the 2016 Presidential Election

    @Khudzlin it's got a brace on the same line as the else, that's what



  • @Jaloopa Ah, you want braces to be all alone. How cruel and intolerant of you.



  • @Jaloopa said in Exception handling is hard:

    @Khudzlin it's got a brace on the same line as the else, that's what

    Yeah. If you're going to put the opening brace on the same line as the else, like this:

    @aliceif said in Exception handling is hard:

    if (condition) {
        // Do stuff
    }
    else {
       // Do stuff
    }
    

    ... then you should also put the else on the same line as the preceding closing brace:

    if(condition) {
        // Do stuff
    } else {
        // Do stuff
    }
    

    Id est, all or none. My preference is all braces on their own lines:

    if(condition)
    {
        // Do stuff
    }
    else
    {
        // Do stuff
    }
    


  • @djls45 I also prefer brace-else-brace to brace-linebreak-else-brace. Closing braces get lonely, too.



  • @RaceProUK That's what you get for changing the variable names from "ex" to "e". :P

    This is indeed C# and it is valid code. But I think VS2016 will complain if you do that by default.



  • @Jaloopa I'm sorry for the messed up indent style. I blame discourse.



  • @Hans_Mueller Not with the new before the ex.



  • @Magus I see. Then it is an error introduced by me. I still blame discourse. :innocent:



  • DOWNVOTED FOR:

    @djls45 said in Exception handling is hard:

    ... then you should also put the else on the same line as the preceding closing brace:



  • @aliceif said in Exception handling is hard:

    @Khudzlin said in Exception handling is hard:

    but the braces are ok.

    else without a leading one?

    Which might imply

    if (condition) {
        // Do stuff
    }
    else {
       // Do stuff
    }
    

    ?

    No, this feels wrong.

    Or it could have been

    if(condition)
        // Do one thing
    else {
        // Do one thing (throw exception)
    }
    

    which is just all kinds of wrong.



  • @boomzilla said in Exception handling is hard:

    DOWNVOTED FOR:

    @djls45 said in Exception handling is hard:

    ... then you should also put the else on the same line as the preceding closing brace:

    I'm just asking for consistency with brace placement. All braces should be either on their own lines (to facilitate seeing code blocks) or on the same lines as the block control keywords (to save vertical space). Anything else is inconsistent and arbitrary.



  • @djls45 said in Exception handling is hard:

    I'm just asking for consistency with brace placement. All braces should be either on their own lines (to facilitate seeing code blocks) or on the same lines as the block control keywords (to save vertical space). Anything else is inconsistent and arbitrary.

    Your definition of consistency is arbitrary. Opening braces are on the line as whatever thing defines them (method, loop, if, etc) and closing braces always get their own lines and never omit them. That's the only brace placing related consistency worth having in one's code.


  • Winner of the 2016 Presidential Election

    @djls45 said in Exception handling is hard:

    All braces should be either on their own lines (to facilitate seeing code blocks) or on the same lines as the block control keywords (to save vertical space).

    When I write C++, I like to have opening braces of classes/namespaces/functions on a new line and opening braces of loops/conditionals on the same line. Yes, I know, :doing_it_wrong:. It looks nice, though.


  • Discourse touched me in a no-no place

    You :wtf:ers are all doing it wrong. The only proper style is like this:

    (if foo
        (bar x y z)
        (baz a b c))
    

    :trollface:


  • Impossible Mission - B

    @antiquarian Sounds like a good way to get Lost In Superfluous Parens.



  • @boomzilla said in Exception handling is hard:

    @djls45 said in Exception handling is hard:

    I'm just asking for consistency with brace placement. All braces should be either on their own lines (to facilitate seeing code blocks) or on the same lines as the block control keywords (to save vertical space). Anything else is inconsistent and arbitrary.

    Your definition of consistency is arbitrary.

    How so? The purpose of any code style standard is to enhance readability, and since braces group related concepts together, having opening and closing braces in the same vertical column helps readability. They make it easy to scan backwards through the code to see where the beginning of the block is.

    I can (sort of) understand the need to save vertical space (in certain contexts), but I much prefer the more readable style.

    Opening braces are on the line as whatever thing defines them (method, loop, if, etc)
    and closing braces always get their own lines
    ...
    That's the only brace placing related consistency worth having in one's code.

    Why though? What purpose does putting the opening brace at the end of a line serve? Especially if the closing brace is always on its own line?

    and never omit them.

    I agree.



  • @djls45 said in Exception handling is hard:

    I can (sort of) understand the need to save vertical space (in certain contexts), but I much prefer the more readable style.

    No, you don't prefer the more readable style, otherwise you'd agree with me. De gustibus non est disputandum. But if you disagree with me your still wrong.

    @djls45 said in Exception handling is hard:

    Why though? What purpose does putting the opening brace at the end of a line serve? Especially if the closing brace is always on its own line?

    It's more readable this way. Why? Dunno...I guess it couples the thing with the block of code in my mind? Based on where I like to put extra newlines to separate stuff, it probably has to do with keeping all the code looking more together / coupled and adding separation at the end, where some new thing (after the block) starts happening.



  • @masonwheeler said in Exception handling is hard:

    @antiquarian Sounds like a good way to get Lost In Superfluous Parens.

    Hey! Don't be calling those parentheses useless! :crying_cat_face:

    @masonwheeler said in Exception handling is hard:

    Lost In Superfluous Parens

    <:robot:>
    Ha. Ha.
    </:robot:>



  • @asdf said in Exception handling is hard:

    When I write C++, I like to have opening braces of classes/namespaces/functions on a new line and opening braces of loops/conditionals on the same line. Yes, I know, :doing_it_wrong:. It looks nice, though.

    Same here. (except the C++ part)


  • Impossible Mission - B

    @djls45 I didn't. I called them superfluous.



  • @boomzilla said in Exception handling is hard:

    @djls45 said in Exception handling is hard:

    Why though? What purpose does putting the opening brace at the end of a line serve? Especially if the closing brace is always on its own line?

    It's more readable this way. Why? Dunno...I guess it couples the thing with the block of code in my mind? Based on where I like to put extra newlines to separate stuff, it probably has to do with keeping all the code looking more together / coupled and adding separation at the end, where some new thing (after the block) starts happening.

    If you're only ever reading downward through the code, sure. But how often do you scan backwards through code to see where a code block begins? Having a little more separation with the opening braces on their own lines assists immensely with that. Your eyes don't have to skip left and right as they scan up, trying to find that opening brace buried at the end of some line of indeterminate length.



  • @djls45 said in Exception handling is hard:

    If you're only ever reading downward through the code, sure. But how often do you scan backwards through code to see where a code block begins? Having a little more separation with the opening braces on their own lines assists immensely with that. Your eyes don't have to skip left and right as they scan up, trying to find that opening brace buried at the end of some line of indeterminate length.

    You just find the next thing that starts at the same indentation level. Doesn't even require looking for a particular character.



  • @djls45 said in Exception handling is hard:

    If you're going to put the opening brace on the same line as the else,
    [...]
    then you should also put the else on the same line as the preceding closing brace:

    That's not an argument in favour of consistency. else is a keyword introducing a new block of statements, just like if, for or while.
    That it needs to have a block preceding it is besides the point.

    Filed under: IMO


  • Impossible Mission - B

    @boomzilla said in Exception handling is hard:

    You just find the next thing that starts at the same indentation level. Doesn't even require looking for a particular character.

    if condition:
        DoOneThing()
    else:
        DoOtherThing()
    

    ???



  • @masonwheeler said in Exception handling is hard:

    @boomzilla said in Exception handling is hard:

    You just find the next thing that starts at the same indentation level. Doesn't even require looking for a particular character.

    if condition:
        DoOneThing()
    else:
        DoOtherThing()
    

    ???

    ??? ??? ???


  • Impossible Mission - B



  • @Hans_Mueller

    Don't you know.... exception throwing is a goto.


  • Impossible Mission - B

    @xaade No, it's really not. And people who make that claim unironically are TRWTF.



  • @djls45 said in Exception handling is hard:

    The purpose of any code style standard is to enhance readability

    Agreed.

    braces group related concepts together

    ...for the compiler. Indenting does that for the human reader.

    having opening and closing braces in the same vertical column

    gives a compiler implementation detail primacy over human readers.

    OTBS brace placements also

    make it easy to scan backwards through the code to see where the beginning of the block is

    since all you do is scan directly upward from a closing brace to the keyword (do, else, for, if, switch, while) whose block you're in.

    Also, since the closing brace is the only one that ever gets a line to itself, it makes a visually distinctive block closing mark even though the overall aspect ratio and weight of both opening and closing braces is fairly similar.


  • Dupa

    your all wrong 'scept for @djls45

    basta!



  • @boomzilla said in Exception handling is hard:

    @djls45 said in Exception handling is hard:

    If you're only ever reading downward through the code, sure. But how often do you scan backwards through code to see where a code block begins? Having a little more separation with the opening braces on their own lines assists immensely with that. Your eyes don't have to skip left and right as they scan up, trying to find that opening brace buried at the end of some line of indeterminate length.

    You just find the next thing that starts at the same indentation level. Doesn't even require looking for a particular character.

    That still requires left-right scanning to find the beginning of a block. A nearly empty line provides a simple and easy vertical space when scanning vertically, which is the point of scanning instead of reading.



  • @flabdablet said in Exception handling is hard:

    @djls45 said in Exception handling is hard:

    braces group related concepts together

    ...for the compiler. Indenting does that for the human reader.

    Technically, that would be the parser, not the compiler, per se, although modern "compilers" do include the parser.

    having opening and closing braces in the same vertical column

    gives a compiler implementation detail primacy over human readers.

    The compiler doesn't care, so how could it be taking priority over human readability?

    OTBS brace placements also

    make it easy to scan backwards through the code to see where the beginning of the block is

    since all you do is scan directly upward from a closing brace to the keyword (case, do, else, for, if, while) whose block you're in.

    That requires the human to do some parsing instead of just scanning.

    Also, since the closing brace is the only one that ever gets a line to itself, it makes a visually distinctive block closing mark even though the overall aspect ratio and weight of both opening and closing braces is fairly similar.

    And having the opening brace on its own line doesn't mark a visually distinctive beginning of a block?



  • @djls45 said in Exception handling is hard:

    That still requires left-right scanning to find the beginning of a block.

    I cannot imagine how you came to this conclusion from what I said. It is literally the opposite.

    @djls45 said in Exception handling is hard:

    A nearly empty line provides a simple and easy vertical space when scanning vertically, which is the point of scanning instead of reading.

    As does the opposite, which is to say, the stuff that precedes the opening brace, which is also easier to spot quickly than something that almost isn't there.

    Face it: if your goal is to out lazy me...


  • Impossible Mission - B

    @djls45 said in Exception handling is hard:

    That still requires left-right scanning to find the beginning of a block. A nearly empty line provides a simple and easy vertical space when scanning vertically, which is the point of scanning instead of reading.

    ...which is part of what makes Python style so nice. You can throw away all the braces (and a lot of other superfluous syntactical noise) and still get very clean code that's easy to scan visually.



  • @masonwheeler said in Exception handling is hard:

    ...which is part of what makes Python style so nice. You can throw away all the braces (and a lot of other superfluous syntactical noise) and still get very clean code that's easy to scan visually.

    If there is ONE thing I hate in Python, is the fact that they threw away braces and replaced them with indentation.



  • @flabdablet said in Exception handling is hard:

    since all you do is scan directly upward from a closing brace to the keyword (case, do, else, for, if, while) whose block you're in.

    This. When I first started out in programming I too did it like this:

    if (condition)
    { 
        doStuff();
    }
    else
    {
        doDifferentStuff();
    }
    

    because I found it more readable. Also you can spot missing opening brackets really fast this way. When I tried it like this

    if (condition) { 
        doStuff();
    }
    else {
        doDifferentStuff();
    }
    

    I found it too confusing. But one day I simply decided to switch to this indendation style and found it much more readable. It also saves vertical space, which I think is a huge plus. And yes, if I want to see what the closing bracket corresponds to, I simply scan upwards until I find something like "if" or "else" or "switch" or whatever. Never really looked for a corresponding opening bracket before, because opening brackets don't tell me what's going on anyway,

    if (condition) { 
        doStuff();
    } else {
        doDifferentStuff();
    }
    

    might be pushing it a little too hard. Yes, it saves another line, which is a huge plus, but now "scanning upwards" is a bit harder to do, since I have to look for a nother closing bracket and then look to the right.

    However, I like doing

    if (condition) 
        doStuff();
    else
        doDifferentStuff();
    

    to save even more space. Yes, I know about the possible risks, but hey, this is what Linus Torvalds suggests, too. :P


  • Impossible Mission - B

    @TimeBandit I actually like that. It's a bit weird getting at first just because it's different, but once you get used to it it's actually really nice.

    The things I really don't like about Python:

    • everything is too dynamic
    • no compiler (how do you give a Python program to a non-technical person with no Python pre-installed?)
    • bizarre and cumbersome OO syntax


  • @masonwheeler I find the lack of braces almost as dumb as Visual Basic's lack of "end of line" character replaced by a "this line continue on the next one" character.


  • Impossible Mission - B



  • @masonwheeler the Python or VB one ? :wink:


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.