Exceptions (2003) • Hacker News Board

Re: Exceptions (2003)

#91

Post by beagle3 » Tue, Sep 03, 2013, 10:15 AM UTC

bjourne wrote: post #87

beagle3 wrote: post #86

Earlier quoted context omitted.

> the function may also throw an exception if a dns lookup error occurred for example. What's wrong with (DNS Lookup Failure, -17), as long as it is documented? why doesn't 404 NOT_FOUND merit an exception, yet a DNS lookup failure does? (I can argue both ways, I'm just trying to point that there's no clear criterion) > therefore can't return a valid result if they occur. Therefore it must throw an exception. But ope…

>> the function may also throw an exception if a dns lookup error occurred for example. > What's wrong with (DNS Lookup Failure, -17), as long as it is documented? why doesn't 404 NOT_FOUND merit an exception, yet a DNS lookup failure does? Because then every function that could potentially cause a dns lookup failure needs to have that error code documented. Then ask yourself this, what's wrong with having (Out of Me…

> Then ask yourself this, what's wrong with having (Out of Memory Failure, -1234) in addition to DNS Lookup Failure and HTTP Status codes?

Indeed, I see nothing wrong with this.

> However, you do not know about DNS lookups or memory allocation therefore if a problem occurs in those areas it is exceptional -> exception.

This is where the disagreement lies. When I imagine myself as an http function FOR MOST USES, I imagine a "full service" function. You give me a URL (+post data), and get back a return code and a page. This functionality is sufficient for 99% of web uses.

If I can't get a 20x (possibly after following a 30x or 401 unauthorized response), the user in 99% of the cases does not care what the reason for failure is - they just need to know it failed and some reason to log/display.

Turn it the other way around: Why should a user of an http library care about internal implementation details like DNS resolving, to the point of needing to include an explicit check for them? And if you're advocating for "catch all exceptions", how is that different from a multiple-return-value?

> Syntactically valid, but not semantically as -1 isn't a valid file descriptor.

So what? It is a valid return from the "open" function. No, you can't use it for reading or writing or ioctl - but then, whether or not you can do that to any other returned descriptor depends on what that descriptor is (/dev/random? /dev/null? a socket?)

I'm not disagreeing that exceptions can be useful. I'm just disagreeing that what is exceptional vs. what is regular is a well defined thing.

Re: Exceptions (2003)

#92

Post by FreeFull » Tue, Sep 03, 2013, 2:07 PM UTC

ghc wrote: post #12

FreeFull wrote: post #7

Some Haskellers treat exceptions as something that you only use if the program has entered an unrecoverable condition and needs to crash.

I don't find this true at all. Haskell exceptions don't look like exceptions in other languages, so it's easy to get hung up on the fact that error is generally used only for unrecoverable errors. But that's why it's called error , not exception . In Haskell, Either and Maybe are used where I would normally use try/except in Python. The only exception to this that I've found is that error is something you may need to…

Well, I didn't think of Maybe and Either as exceptions, but rather considered undefined/error. The exceptions from Control.Exception are probably the closest to exceptions in other languages, and I think those are built on error.

Re: Exceptions (2003)

#93

Post by twic » Fri, Sep 06, 2013, 5:46 PM UTC

comex wrote: post #57

twic wrote: post #49

Earlier quoted context omitted.

In Java, everyone would tell you this is wrong. In Python, this is the normal way to end an iteration (specifically, throwing StopIteration). It's not a huge leap to see a stream as an iteration over bytes. So, what's considered exceptional seems somewhat culturally dependent.

Note that in Python you usually use the syntactic sugar of for loops rather than interacting with StopIteration manually.

True! I should have made that clearer.

The only time you need to think about StopIteration is if you're consuming from an iterator in some unusual way (eg writing a "get me the single item which is in this iterator, or blow up if there are zero or more than one" function) or if you're writing an iterator which is not built out of building blocks which already know how to stop an iteration.

So, not often.