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#.
-
@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?
-
@Hans_Mueller Is that Java? Because it's not valid C#:
-
@RaceProUK I was wondering if there was a C# feature I was unaware of.
Also, that brace/indent style hurts my eyes
-
@Jaloopa said in Exception handling is hard:
Also, that brace/indent style hurts my eyes
His or mine?
-
@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
-
@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?
-
@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 whatYeah. 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 theex
.
-
@Magus I see. Then it is an error introduced by me. I still blame discourse.
-
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.
-
@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, . It looks nice, though.
-
You ers are all doing it wrong. The only proper style is like this:
(if foo (bar x y z) (baz a b c))
-
@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!
@masonwheeler said in Exception handling is hard:
Lost In Superfluous Parens
<>
Ha. Ha.
</>
-
@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, . It looks nice, though.
Same here. (except the C++ part)
-
@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 likeif
,for
orwhile
.
That it needs to have a block preceding it is besides the point.Filed under: IMO
-
@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()
???
??? ??? ???
-
@boomzilla !!! !!! !!!
-
Don't you know.... exception throwing is a goto.
-
@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.
-
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...
-
@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
-
@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.
-
@TimeBandit Why?
-
@masonwheeler the Python or VB one ?