Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Isaacs: try/catch is an anti-pattern

groups.google.com

Post reply on HN
Print view View original

81–90 of 140 posts

Re: Isaacs: try/catch is an anti-pattern

#81

Post by kstenerud »

Rule #1 of programming articles: Be wary of anyone who states "always" or "never" or "harmful" or "evil" with regards to a code construct/idiom/pattern.

What they're telling you, in effect, is that they know everything there is to know about X, and so you should trust their judgment and not think for yourself.

And in every case I've seen so far (including the famous goto debacle), they have merely focused on their pet code, ignoring the actual cases where the construct is useful (most often, they'll include trivial examples when the construct is meant to be used in complex situations), and this article is no exception.

When your argument becomes "we should throw this out because bad programmers use it badly", you have no argument.

Re: Isaacs: try/catch is an anti-pattern

#82

Post by pyre »

dchest wrote: post #9

This seems to be exactly the attitude of Go: "We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional. Go takes a different approach. For plain error handling, Go's multi-value returns make it easy to report an error without overloa…

This:

  > We believe that coupling exceptions to a control
  > structure, as in the try-catch-finally idiom,
  > results in convoluted code.
Seems at odds with this:

   f, err := os.Open("filename")
   if err != nil {
      // handle error
   }
You're still using a control structure (if-statement) to handle the error.

Re: Isaacs: try/catch is an anti-pattern

#83

Post by chollida1 »

Dylan16807 wrote: post #78
chollida1 wrote: post #76

Earlier quoted context omitted.

I'm sorry, I can't really parse your argument. My point was that there is a school of htought that exceptions should only be used in "exceptional" circumstances. The examples given were not exceptional in that a programmer should expect those types of errors during the normal execution of their program. Therefor exceptions aren't the solution to those types of errors. Does that make more sense to you?

But using that school of thought to support that school of thought isn't an argument, it's a circle. PaulHoule is explaining why he likes a specific mechanism compared to another, and you are only replying with the previously-established fact that there exists a disagreement here, not a counterargument.

I get what your saying, I just disagree.

And I think alot of people take my point of view as evidenced by the votes my initial post received.

No worries, thanks for the point of view:)

Re: Isaacs: try/catch is an anti-pattern

#84

Post by SourPatch »

PaulHoule wrote: post #31
dchest wrote: post #9

This seems to be exactly the attitude of Go: "We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional. Go takes a different approach. For plain error handling, Go's multi-value returns make it easy to report an error without overloa…

This is a bad idea that keeps coming back again and again. I see nothing wrong with exceptions, I do have a problem with (1) checked exceptions, and (2) catching exceptions prematurely and (3) people not learning how to use "finally" so they do (2) and rethrow. Languages like Go and Scala roll out various mechanisms that bring us back to the bad old days of C, when we had to check the return/value and or the error co…

How does Scala contribute to this problem? It does not have checked exceptions.

Re: Isaacs: try/catch is an anti-pattern

#85

Post by amalcon »

exDM69 wrote: post #55

An interesting read. It's always nice to see people stating their unpopular opinions with proper reasoning. The author's point of view seems to be pretty Javascript/Node.js -centric. I can relate. try/catch and node.js -style asynchronous coding do not work together. However, I'd say that it's the async programming model that is broken, not try/catch. Writing code in node.js async style is very difficult for humans t…

I think the real problem here is that JavaScript/Node.js is constrained by language choice to a hybrid continuation-passing/call-return style. As straightforward as exceptions are in call-return, they are even simpler in CPS -- the exception handler is just a second continuation. It's literally just a standard-form onError parameter.

The problem is that you can't write your whole program in continuation-passing style in JavaScript, because its call and exception mechanisms aren't designed for CPS. There is no tail-call optimization, and you can't configure exception handlers manually. That's a valid choice under the right circumstances, but it breaks CPS.

Re: Isaacs: try/catch is an anti-pattern

#86

Post by vog »

TylerE wrote: post #47
gizmo wrote: post #33

Earlier quoted context omitted.

> when we had to check the return/value and or the error code after every function call... if we wanted error handling to work. Errors as return values force you to think about every possible error, which is a good thing for code quality. Look at how much rock stable C software we have out there. Software that can be compiled on many different architectures, run in many different environments, and it all just works,…

> Look at how much rock stable C software we have out there. Which would be what exactly. The work of Knuth and djb I'll grant you, but the rest?

*BSD kernels, GCC, tar, gzip, ...

Re: Isaacs: try/catch is an anti-pattern

#87

Post by Jach »

tef____ wrote: post #60

''Try/catch is goto wrapped in pretty braces.'' From this I can infer that lambda is also an anti pattern. But as good as this straw man post is, yes you can mis-use exceptions, No that doesn't make it an anti pattern.

Glad I wasn't the only one thinking of Lambda: The Ultimate GOTO

Re: Isaacs: try/catch is an anti-pattern

#88

Post by kinghajj »

pyre wrote: post #82
dchest wrote: post #9

This seems to be exactly the attitude of Go: "We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional. Go takes a different approach. For plain error handling, Go's multi-value returns make it easy to report an error without overloa…

This: > We believe that coupling exceptions to a control > structure, as in the try-catch-finally idiom, > results in convoluted code. Seems at odds with this: f, err := os.Open("filename") if err != nil { // handle error } You're still using a control structure (if-statement) to handle the error.

But that control structure isn't specific to handling errors, unlike try/catch. I think that's what they meant.

Re: Isaacs: try/catch is an anti-pattern

#89

Post by dasil003 »

eftpotrm wrote: post #45
gizmo wrote: post #33

Earlier quoted context omitted.

> when we had to check the return/value and or the error code after every function call... if we wanted error handling to work. Errors as return values force you to think about every possible error, which is a good thing for code quality. Look at how much rock stable C software we have out there. Software that can be compiled on many different architectures, run in many different environments, and it all just works,…

And you know what? In my experience it's not less robust. So my code hasn't had every possible failure case thought through and explicitly handled in advance. That's good. Firstly some of those errors are so rare they'll almost certainly never occur in my program's lifetime; by not having to handle them explicitly and individually I save time and money. Secondly I can guarantee that, no matter how good I think I am,…

Just because you think a certain error will never happen for the lifetime of a program doesn't mean that not explicitly handling it is equally robust.

Re: Isaacs: try/catch is an anti-pattern

#90

Post by jerf »

nogden wrote: post #77
exDM69 wrote: post #55

An interesting read. It's always nice to see people stating their unpopular opinions with proper reasoning. The author's point of view seems to be pretty Javascript/Node.js -centric. I can relate. try/catch and node.js -style asynchronous coding do not work together. However, I'd say that it's the async programming model that is broken, not try/catch. Writing code in node.js async style is very difficult for humans t…

>> However, I'd say that it's the async programming model that is broken, not try/catch. This is an interesting point of view, however I'm inclined to disagree on the basis that the async model is representative of how things actually happen; the imperative model is not. In an asynchronous architecture, the developer is concerned with only the current state and the set of all events that may cause a transition from t…

"This is an interesting point of view, however I'm inclined to disagree on the basis that the async model is representative of how things actually happen; the imperative model is not."

Have you used Erlang or Haskell? I have heard this line of defense a number of times, but always from people who have to answer "no".

The claim is that it's better to let the compiler handle the issues. You're response is basically that since you learned how to more properly run what the compiler does in your head, you've done better. I would submit that's support for the idea that a compiler should be doing the work, not evidence against. What if you could skip the part where you didn't know how, then skip the part where you had to learn better, and then skip the part where you're running this algorithm in your head, and just let the compiler do it for you from day one, and probably better than you can do it even with experience?

(Humans suck at maintaining invariants. It takes years of experience to even be sort of good at it, and you'll still be terrible compared to a compiler.)

While you should know what the compiler is doing to your code, this is hardly any different than manually implementing the C stack on every function call. The fact that it may occasionally let you do something clever doesn't get around the fact that you really shouldn't be thinking about this on every single function call at all.

Post reply on HN