Bruno Jouhier's response nails it. It's funny, but for whatever reason I almost always disagree with Isaac's (perfectly reasonable) points of view.
Isaacs: try/catch is an anti-pattern
11–20 of 140 posts
Re: Isaacs: try/catch is an anti-pattern
#12> Try/catch is goto wrapped in pretty braces. There's no way to continue where you left off, once the error is handled.
...
> But still, nothing is as bad as the common "On Error Resume Next" that so many terrible VB programs start with.
Assuming "On Error Resume Next" does what I think it does, you can't complain about both of these at once.
Re: Isaacs: try/catch is an anti-pattern
#13"The really nice thing about the cb(error, result) approach is that it constantly reminds the programmer that you must acknowledge that failure may come from any request you make."
Re: Isaacs: try/catch is an anti-pattern
#14I'm not sure how I'm supposed to read this... I guess I need an account?
Sometimes Google Groups ask for an account, sometimes don't -- not sure why.
Anyway, here's the post: http://pastie.org/2861111
Re: Isaacs: try/catch is an anti-pattern
#15The core of the post:
try/catch, which blurs the line between errors
that are *mistakes* (accessing a property of null,
calling .write() on a stream after .end(), etc.),
and those which are expected application-level problems
(invalid data, file missing, and so on).
Re: Isaacs: try/catch is an anti-pattern
#16The problem with try/catch, really, is that it makes a tremendous amount of visual noise, which makes sense for critical operations that might crash everything, but just don't make sense when you can tolerate certain errors or checking for proper output with with a conditional looks better and is more appropiate. Obviously then you have an issue with language conventions. How do you check for the returns of a method…
But what is your alternative? Doesn't checking the return code of every statement also make a tremendous amount of visual noise?
I've seen C code where about 80% of the code is dedicated to error handling and corner cases. Before every statement it has to check the current error status, and after it the return value... it's almost unreadable.
With try/except/finally a lot of that can be cleaned up, by handling the errors higher-up in the call hierarchy where they make sense to handle.
I see a lot of critique of exceptions, but haven't seen one better alternative yet, at least one that doesn't require switching to an obscure programming language.
Edit: this does assume that exceptions are used properly: for errors that should bubble up, not as extra return value.
Re: Isaacs: try/catch is an anti-pattern
#17OT: Was it always like this that the top 170px are just fixed on groups.google.com and thus are somehow wasted from the horizontal space?
http://www.az2000.de/pics/screenshots/Screen%20Shot%202011-1...
Re: Isaacs: try/catch is an anti-pattern
#18This is the standard in many languages and one that I believe that java got wrong. It was a little rushed with the whole concept of forcing everyone to handle all exceptions concept and building so many exceptions in for silly things like connection failures and parsing errors that reasonably can be expected to happen constantly in the normal runtime of an application. I follow the rule in almost every language that…
> It was a little rushed with the whole concept of forcing everyone to handle all exceptions
Just to clarify, Java doesn't force you to handle all exceptions (maybe it did at one point in time?). Exceptions which inherit from RuntimeException are unchecked and you can choose whether to handle them or not. Exceptions which don't inherit from RuntimeException are checked
Re: Isaacs: try/catch is an anti-pattern
#19As we say in C++ "exceptions should be exceptional".
Re: Isaacs: try/catch is an anti-pattern
#20> Try/catch is goto wrapped in pretty braces. There's no way to continue where you left off, once the error is handled. ... > But still, nothing is as bad as the common "On Error Resume Next" that so many terrible VB programs start with. Assuming "On Error Resume Next" does what I think it does, you can't complain about both of these at once.
"On Error Resume Next" does not do what you think it does. It ignores the error, and marches blithely on. That is very different than "continuing where you left off, once the error is handled."