Hacker News Reader

Comment by xg15 | Hacker News Reader

You can have the same philosophical distinction over the term "error". Is it really an error if your computer did not literally catch fire or otherwise took physical damage?

And yet this hasn't stopped even nontechnical people from using the term without any significant communication problems.

I think a more interesting discussion might be what exactly the difference between "errors" and "exceptions" is in computing, though I'm not sure there is one in practice. (I think in theory, "errors" are supposed to be caused by factors external to your program, like hitting memory constraints, while "exceptions" are internal to your program? I'm not sure if this is universally true though or just a java-ism - and even in java it's not consistently followed through everywhere).

So until this is decided, I think the most useful practical definition of exceptions is "it's a special language construct that makes it easier to manage errors".

View on HN

There was a book “C Interfaces and Implementations” by David R. Hanson and he put it so: there are user errors (input/data errors), program bugs (things we 'assert') and everything else are exceptions. So a non-existent file is a user error, uninitialized memory is a program bug, and an arithmetic overflow is an exception. Not sure if this is useful.

I myself think errors and exceptions are misleading terms. There is an instruction; it does this and that and can produce the following results. We call some of there results errors because usually we imply a goal. But instructions do not really have goals. We search for a key in a dictionary and either find it or not. Either result can be an error or not an error depending on whether we expect the key to be there or want to make sure it does not exist. Yet the searching instruction is same. There is no reason to prefer one result or another. It is more important to make all the necessary distinctions.

> There was a book “C Interfaces and Implementations” by David R. Hanson and he put it so: there are user errors (input/data errors), program bugs (things we 'assert') and everything else are exceptions. So a non-existent file is a user error, uninitialized memory is a program bug, and an arithmetic overflow is an exception.

I don't agree with this definition in the same way I don't agree with many others not found in books.

These definitions always reflect the personal view of their authors, but are fundamentally just an interpretation of their own thoughts. There is nothing objective about it. It's just a philosophical or semantic debate.

For example, why is uninitialized memory a bug, but an arithmetic overflow is not? In both cases it would have been the developers responsibility to initialize the memory and prevent an arithmetic operation that overflows.

In his interpretation exceptions were just a little short of being fatal errors. They were almost fatal errors but with an optional escape hatch. But I agree all these distinctions are vague and do not seem to be fundamental differences.

Exceptions are a side effect of nice syntax. When we write

    a = b + c

in a modern language quite a lot can happen behind the scenes. Yet the form implies 'a' will always be a sum of 'b' and 'c' whatever this means. There is no notion of 'a' not being a sum. So it seems there are two ways: either we provide a separate error handling mechanism (exceptions) that stops the execution and leaves 'a' undefined or we somehow turn 'a' into either a sum of 'b' and 'c' or an error (sum types).

Errors have the connotation that something has gone wrong, exceptions do not. Exceptions as used in CS also do not have the connotation that they are unusual, as pointed out by the article. But generally, every error can be made into an exception.

As far as deciding on what they mean, I have brought up ChatGPT's definitions in arguments and been laughed at. People seem more interested in arguing than in making their vocabulary precise.

Reply on news.ycombinator.com