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

91–100 of 140 posts

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

#91

Post by jberryman »

nosequel wrote: post #38
PaulHoule wrote: post #31

Earlier quoted context omitted.

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 do you feel about Erlang's "let it fail" policy? I personally was afraid of it at first thinking you couldn't write stable code, but the result was quite the opposite. Things fail, and get started back up by supervisors and everything is happy. No error checking and code bulk, no try/catch nonsense littered all over the code.

just curious: what are you using erlang for?

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

#92

Post by dasil003 »

Exceptions vs error codes seems closely related to dynamic vs strong-typing ala Haskell.

If you use error codes exclusively, then it's possible to do much stronger reasoning about all code paths, and you can create a more robust system. It doesn't have the magic of the static analysis that Haskell's type system enables, but there is a certain "purity" in that no function can have an error pass through it in the call stack without being aware of it. This is exactly what you need in systems programming like an OS kernel where every conceivable thing will go wrong and your goal is to handle everything gracefully.

On the other hand, when writing business apps, you not only have the technical concerns of the system, but your program is primarily a big hairy rat's nest of business logic which may never achieve well-definition. In such circumstances, you never get to a point of stability where you can be so pedantic about the technical details because you have your hands full just trying to meet the ever-changing business requirements. Exceptions are a great help here because they allow you to handle new errors with minimal ceremony and function redefinitions. Just like Ruby duck-typing, this means you can refactor faster, but obviously in a dramatically less robust fashion than Haskell. But if you're operating in an environment where a logical failure here or there is acceptable and code has a short half-life, then you'll get better ROI from duck-typed, unit-tested, exception-notifying code than you will from nearly-impossible-to-fail statically-typed code.

A lot of code probably falls into a gray area where it becomes largely a matter of programmer taste.

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

#93

Post by ww520 »

albertzeyer wrote: post #17

OT: 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...

OMG. That is a horrible UI. It makes Groups totally unusable. Half of my laptop vertical screen is the unscrollable fixed panel with a few big buttons and the search bar. Then 1/4 of the horizontal screen is fixed with the left navigation links. The actual content are crammed on the lower right half of the screen. The bottom arrow of the scrollbar is missing. Please Google, not everyone has 24-inch vertical monitor.

It used to be that Microsoft's website took up lots of fixed upper screen real estate for "branding." Now they have fixed it and is much more usable. Have the Microsoft designers gone to work for Google now?

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

#94

Post by eftpotrm »

dasil003 wrote: post #89
eftpotrm wrote: post #45

Earlier quoted context omitted.

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.

No, I agree, but there's a cost/benefit calculation to be done. Plus it's not like the try...catch solution that doesn't explicitly handle the error will blow up and destroy everything; if the program is properly designed it should merely degrade onto the path of general handling, log the failure and halt whatever was being done.

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

#95

Post by Lagged2Death »

dpark wrote: post #70
Lagged2Death wrote: post #57

Earlier quoted context omitted.

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. I am probably one of those people who catches exceptions prematurely and who hasn't learned to use "finally." If you link to some advice on how to use such things, I'll read it. I want to believe that I can learn a better way to use exceptions, but they…

> The .NET library designers already decided what counts as exceptional, and it's often not possible for me, as a .NET user, to decide much of anything about the use or placement of try/catch. What do you mean? You can certainly decide what's exceptional. You can roll your own exceptions. You can catch and discard or handle exceptions you don't want to bubble up. You can put try-catch everywhere or nowhere (or choose…

You can certainly decide what's exceptional.

I can decide to make something in my code exceptional, sure. I can't decide to make something in the library not-exceptional, though.

You can put try-catch everywhere or nowhere (or choose a reasonable place in between).

This isn't always the case. Sometimes the only way to answer a question ("Can this string be parsed as an integer?") is to try it and catch the exception. And there's just no way to do that coherently without catching it immediately.

Later releases of .NET do include a non-exception-throwing TryParse() call in many places. I'm pretty sure I've run into some cases where that was not available, however, and I'm pretty sure I've run into similar situations in other methods besides Parse(). And TryParse() was a late addition; look back in the 1.1 or 2.0 docs, and it doesn't exist.

In other words, somebody thought it was reasonable to force .NET users to catch some exceptions immediately.

Your hands are not tied by .net exceptions...

No, but there's not much point in using .NET if I'm not using the library that comes with it. And the design of the library does tie my hands in some cases.

I think the author makes a great point about libraries that use exception handling blurring the line between bugs and expected problems. That's exactly how I feel about the C# work I've done.

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

#96

Post by sgt »

colanderman wrote: post #51

I think a lot of programmers use try/catch when what they really want is Prolog-style failure: my_parser(String, Output) :- parseJSON(String, JSON), extract_the_values_I_want(JSON, Output). if my_parser(String, Output) then ...do stuff with Output... else ...show user "couldn't parse" message... I've been using Mercury (a strongly typed Prolog) for years now and have never once found the need for exceptions (which Me…

What are your motivations for using Mercury? Are you using it for hobby projects, research/academic purposes or actual production code?

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

#97

Post by TylerE »

vog wrote: post #86
TylerE wrote: post #47

Earlier quoted context omitted.

> 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, ...

BSD kernels have had numerous exploits over the years. GCC is a massive hairball. gzip has had exploits (http://www.kb.cert.org/vuls/id/381508 for one).

Care to try again?

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

#98

Post by nosequel »

jberryman wrote: post #91
nosequel wrote: post #38

Earlier quoted context omitted.

How do you feel about Erlang's "let it fail" policy? I personally was afraid of it at first thinking you couldn't write stable code, but the result was quite the opposite. Things fail, and get started back up by supervisors and everything is happy. No error checking and code bulk, no try/catch nonsense littered all over the code.

just curious: what are you using erlang for?

Backend / Server software, build tools, general scripting (using escript).

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

#99

Post by Periodic »

pilif wrote: post #50

> I much prefer php's json_decode function, since it just returns `null` on invalid input. A function which has the same result in case of an error as when given valid input (hint: 'null' is a valid json string) is neither good design, nor something I would actually 'prefer'. Aside of that (and more to the point of the original article), I do believe that exceptions can be very useful the deeper the abstraction of yo…

I thought a JSON document had to have either a top level object or array, which would make a bare null an invalid JSON text. Granted, we might not be that strict all the time.

See section 2, paragraph 2: http://www.ietf.org/rfc/rfc4627.txt?number=4627

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

#100

Post by je42 »

I dont understand this. According to some believe exceptions should be used in an exceptional context. Can anybody define what exceptional is?

I use exception to get the context in which the error happend. Call stack, variables, stuff like that. I can log it, i can give good error message to the user. I never think about if an error is exceptional.

Post reply on HN