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

61–70 of 140 posts

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

#61

Post by TylerE »

gaius wrote: post #56
TylerE wrote: post #48

Earlier quoted context omitted.

No he doesn't. defaultdict provides a default value for ALL missing values. His approach allows him to target one key in particular, and is a very common python idiom.

I'm confused - where does that come from? >>> x.getDefault(1, 'Que?') Traceback (most recent call last): File " ", line 1, in x.getDefault(1, 'Que?') AttributeError: 'dict' object has no attribute 'getDefault'

Because it's actually (somewhat confusingly, called setdefault).

    >>> a = {1:'foo',2:'blah'}
    >>> a.setdefault(1,'default')
    'foo'
    >>> a.setdefault(4,'default')
    'default'
    >>> a
    {1: 'foo', 2: 'blah', 4: 'default'}
This actually updates the underlying datastructure. Very handy when you want to deal with nested structures, since you can do something like:

    matches.setdefault(keyword,[]).append(s)
This will append s to the list in matches[keyword] if it exists, or set matches[keyword] to [] and then append.

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

#62

Post by andregawron »

jwr wrote: post #8

Anybody who wants to judge try/catch should first go and read about Common Lisp's condition system. See for example the chapter about conditions and restarts from the excellent book "Practical Common Lisp" by Peter Seibel: http://www.gigamonkeys.com/book/beyond-exception-handling-co... Notice I'm not saying you should go and program in Common Lisp, just that you should understand those ideas before you engage in any…

Inspired by Lisp's condition system I wrote a ruby library which comes pretty close to Lisp's error handling. It also implements "restarts" ... a little bit messy though since, as you said, low-level execption are used to get it working. In one point the condition system bootstraps itself which is quite interesting to think about.

https://github.com/melkon/conditions

An example ("parse_log_file" and "log_analyzer show restarts"): https://github.com/melkon/conditions/blob/master/example/exa...

In the beginning I thought it can only be ported to Ruby because I used some Ruby-specific features. The exception solution (which I implemented later) should work in a lot of different languages though.

Another thing is, if you understood the condition system, you can use it for a lot of different things besides error handling. You can build protocols on top of that, event handling etc. Freedom is yours.

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

#63

Post by [deleted] »

phzbOx wrote: post #39

I think the best is a little of both ways. For instance in python: x = some_dict['meh'] Will raise if 'meh' doesn't exist. If you believe that 'meh' should be there in your program, it's fine to 'let it raise an exception'. However, if 'meh' could be there, it's better to use an error style such as: x = some_dict.getDefault('meh', 'some-neutral-value') And continue without raising because there's no need to raise as…

[deleted]

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

#64

Post by eeperson »

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…

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 code after every function call... if we wanted error handling to work.

I cant speak for Go but Scala's Option type is very different from C error codes since it is a monad. As a result you can use it with Scala's 'for' comprehensions (which are roughly the same as Haskell's arrows) and write code that looks roughly imperative without having to explicitly handle any errors.

http://www.scala-lang.org/api/current/index.html#scala.Optio...

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

#65

Post by aufreak3 »

jwr wrote: post #8

Anybody who wants to judge try/catch should first go and read about Common Lisp's condition system. See for example the chapter about conditions and restarts from the excellent book "Practical Common Lisp" by Peter Seibel: http://www.gigamonkeys.com/book/beyond-exception-handling-co... Notice I'm not saying you should go and program in Common Lisp, just that you should understand those ideas before you engage in any…

Spot on, but CL's error generation/capture/recovery mechanism only helps in single-threaded code composition. Erlang's model of linking up processes so that a "supervisor" process get notified if a servant dies is the counterpart in a concurrent scenario. Together, they seem to me to cover most of the ground.

Furthermore, in Haskell you can throw an exception to another thread, though I'm not sure whether that's any more valuable as a design tool than a plain message passing channel. (see also "throwTo & block statements considered harmful" http://www.haskell.org/pipermail/haskell-cafe/2006-December/...)

Go's "defer" is nice syntax btw.

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

#66

Post by jjclarkson »

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

At my (admittedly meager) 1024x768, between browser and now the google groups redesign, ui area takes up almost half of the upper space before any content is shown.

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

#67

Post by sausagefeet »

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…

I don't think this style is much better than exceptions. I think Go could have done itself a favor if it has variants + pattern matching. I find those to be, in many cases, superior to exceptions as the compiler checks you are handling everything and you can easily encode success and failure in the variant type.

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

#68

Post by Dylan16807 »

chollida1 wrote: post #52
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…

I think the point is that your specific cases: > Many programmers in many situations would be perfectly happy to catch "failure to open a file" and "failure to open a database connection" and "failure to connect to a network host" with one simple handler that logs the failure and either aborts, retries or ignores. aren't exception appropriate a according to a certain portion of developers. The reason they aren't exce…

As far as I can tell either your point is a circular argument or it's an English-language nomenclature complaint fixable by s/exception/fooglewoo/.

Either way it doesn't address the real argument, about where it is appropriate to use try and catch. What is inherently better about multiple return values at every level, compared to semi-centralized catch blocks?

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

#69

Post by Dylan16807 »

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…

It was pointed out later in the thread that it should have been 'undefined' rather than 'null'.

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

#70

Post by dpark »

Lagged2Death wrote: post #57
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…

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 a reasonable place in between). Your hands are not tied by .net exceptions any more than they are tied by any other reasonable error handling model.

Post reply on HN