My philosophy of exceptions: they're always ambiguous (2021)

The code that catches an exception can continue, but the point was about the code that threw the exception. You throw an exception if you can't continue the work you're currently doing, for whatever reason. Of course, the rest of the program can very well continue: some other part will catch the exception you threw and decide what to do next. Ending the entire process is an extreme case, that should be reserved for only global problems - out of heap space errors, memory corruption, security violations, deadlock detection. Anything else should result in a more localized failure - killing a thread, a task, a request processor etc.

Also, there is little fundamentally different between throwing an exception and returning an error result. Everything I wrote above applies just as much to error results as it does to exceptions. Exceptions are just a language-level mechanism to help with a common error pattern: the code that detects an error condition is typically very far away from the code that can handle that error condition. When an error happens, the vast majority of the time, what happens next is that the error will be cascaded back through the call chain to a handler function of some kind. Along the way, some context will be added to the error, and some resources will be cleaned up. You can do this by hand, as you would in Go or Rust, or you can have the runtime do it for you, like in Java or C#. There are pros and cons to both (implicit vs explicit, how relevant is the context, etc), but fundamentally the program will take the exact same path.

> Here’s the big lie: in Python, this snippet will almost always raise an Exception. That’s because most users, faced with an input prompt, will press Ctrl+C or enter a non-URL. And even if they enter a URL, it probably has a typo.

[citation needed]

> In English, “exception” means, “something unusual.” But if this code snipet raises ValueError 60 per cent of the time and prints the contents of a web page 10 per cent of the time … well, surely we need a new term?

The purpose of this code snippet is to download a web page and show it to the user. The code considers situations that lead to it not fulfilling its purpose “exceptional”. If someone exits when they see a prompt for a URL, or type gibberish, why did they run a program to download a web page in the first place?

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

Braindead take.

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.