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

Exceptions (2003)

joelonsoftware.com

Post reply on HN
Print view View original

81–90 of 93 posts

Re: Exceptions (2003)

#81

Post by ScottBurson »

mindslight wrote: post #43
beagle3 wrote: post #17

Everyone here seems to agree that "exceptions are for exceptional conditions". The problem is that when you get down to details, there is disagreement about what exactly is an "exceptional condition". e.g. - you are trying to open a file for reading. The file does not exist. Is this exceptional? That depends on context, but the function that opens the file, being in an independent library, is usually designed without…

Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…

> Multiple values make the most sense, but those are ad-hoc product types, so you're eschewing the type system in favor of informal invariants.

Maybe the right approach would be to enrich the type system so that it can express those invariants.

Re: Exceptions (2003)

#82

Post by [deleted] »

jeffdavis wrote: post #54

I think there is reasonable consensus about some software engineering best practices: 1. Avoid action-at-a-distance and side-effects that are hard to reason about. 2. Use immutable objects and values rather than references and pointers. 3. Avoid intricate control flow with many branches. 4. Greater isolation of processes/threads (actor model). 5. Use systems and platforms with simple and strong guarantees (e.g. ACID)…

[deleted]

Re: Exceptions (2003)

#84

Post by detrino »

Forcing a function call to handle an exceptional condition when it doesn't know how doesn't really add anything but bloat to your source code (violating DRY). It's interesting the author mentions goto, because without exceptions goto is often the most reasonable but more error prone way to handle cleanup. C++ solves this using RAII, if you need something to run before the end of the scope, stick it in a destructor. This is very easy and far more composable.

Re: Exceptions (2003)

#85

Post by beagle3 »

mindslight wrote: post #43
beagle3 wrote: post #17

Everyone here seems to agree that "exceptions are for exceptional conditions". The problem is that when you get down to details, there is disagreement about what exactly is an "exceptional condition". e.g. - you are trying to open a file for reading. The file does not exist. Is this exceptional? That depends on context, but the function that opens the file, being in an independent library, is usually designed without…

Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…

Completely agree with the gist of what you are saying, but exceptions are MORE than just a sum/product/extended value type: They are a non-local return. You're obviously aware of that, from the Java comment, but seem to consider that fact an implementation issue of Java, whereas most people consider this a defining attribute of exceptions.

Re: Exceptions (2003)

#86

Post by beagle3 »

bjourne wrote: post #42
beagle3 wrote: post #17

Everyone here seems to agree that "exceptions are for exceptional conditions". The problem is that when you get down to details, there is disagreement about what exactly is an "exceptional condition". e.g. - you are trying to open a file for reading. The file does not exist. Is this exceptional? That depends on context, but the function that opens the file, being in an independent library, is usually designed without…

The rule is that all functions should return a valid result or not return at all. Aka the Samurai Principle: http://c2.com/cgi/wiki?SamuraiPrinciple However, an important point is that a "valid result" maybe a status indicating what went wrong. For example, a function that reads an http url may return (OK, 200), (NOT_FOUND, 404), (REDIRECT, 301) and so on. But in addition to that, the function may also throw an excep…

> 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 open() in C does return a valid result on any of those billion reasons: (fd -1, errno reason). Yes, errno is returned in a global variable, but it is still a return from the open() call. Therefore, exceptions are never needed according to your logic?

Re: Exceptions (2003)

#87

Post by bjourne »

beagle3 wrote: post #86
bjourne wrote: post #42

Earlier quoted context omitted.

The rule is that all functions should return a valid result or not return at all. Aka the Samurai Principle: http://c2.com/cgi/wiki?SamuraiPrinciple However, an important point is that a "valid result" maybe a status indicating what went wrong. For example, a function that reads an http url may return (OK, 200), (NOT_FOUND, 404), (REDIRECT, 301) and so on. But in addition to that, the function may also throw an excep…

> 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 Memory Failure, -1234) in addition to DNS Lookup Failure and HTTP Status codes?

Think of yourself as a http function. You know about the http protocol and therefore from your perspective a 404 NOT_FOUND is a valid result. However, you do not know about DNS lookups or memory allocation therefore if a problem occurs in those areas it is exceptional -> exception.

On the other hand, if you were a memory allocator function then returning out of memory instead of an address to the allocated memory would be fine. Because memory handling is your job.

> But open() in C does return a valid result on any of those billion reasons: (fd -1, errno reason).

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

Re: Exceptions (2003)

#88

Post by rwallace »

Most of the discussion about exceptions tries to think about it in abstract terms, which doesn't work. The point of exceptions is a very concrete one: often the code that runs into an error and the code that handles it are separated by ten levels of function calls. Without exceptions, the logic for detecting and passing on the error has to be duplicated in every function in every one of those levels.

Exceptions are arguably the one feature of C++ that isn't just syntax sugar over C, the one feature that makes the language fundamentally more expressive: they reduce a certain kind of code complexity from O(N) to O(1).

Re: Exceptions (2003)

#89

Post by teddyh »

recursive wrote: post #73
ghc wrote: post #16

Earlier quoted context omitted.

Certainly not. In Python, for example, exceptions are used to handle exceptional conditions . Here's an example. Say I'm writing a function and I have a dictionary I need to access values from often. Now say that 85% of the time the key I need is in the dictionary, but 15% of the time it is not. I could do this: if key in my_dict: execute_operation(my_dict[key]) else: pass So that if the key is not in the dictionary…

Python also has a `StopIterationError` that is raised to signal the end of a `for` loop, which is not exceptional at all.

It's called "StopIteration", not "StopIterationError", because it is not an error.

Re: Exceptions (2003)

#90

Post by mindslight »

beagle3 wrote: post #85
mindslight wrote: post #43

Earlier quoted context omitted.

Vague value judgments ("only for exceptional conditions") are the inevitable result of a failure to reason. The semantic function of exceptions is just a way for summing additional values onto the return type of a function because it has results that are not contained within the primary type. In this way, they are a more general and better typed version of NULL (which has it's places - contrary to the modern dogma, t…

Completely agree with the gist of what you are saying, but exceptions are MORE than just a sum/product/extended value type: They are a non-local return. You're obviously aware of that, from the Java comment, but seem to consider that fact an implementation issue of Java, whereas most people consider this a defining attribute of exceptions.

They're restricted to only escaping currently active stack frames, not jumping anywhere like full continuations. They're basically equivalent to having a default cascade of

    if (ret == -1) return -1;
after every function invocation, which is why I was calling that aspect a syntactic feature.

It's this implicit return after every function that trips people up (when prematurely exiting from stateful computation). So what I was saying that making the call of an exception-throwing function (slightly) more verbose would alleviate that and pay for the complexity where it was used.

Post reply on HN