What is the point of nothrow?

[Neia Neutuladh]

On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
> Why do you care about detecting code that can throw an Error? 
> Errors are supposed to kill the program, not get caught. As 
> such, why does it matter if it can throw an Error?

Error is currently used for three different things:
* This is a problem that could occur in such a wide range of 
circumstances, it would make it difficult to use nothrow.
* This is a problem severe enough that almost every program would 
have to abort in these circumstances, so it's reasonable to abort 
every program here, and damn the few that could handle this type 
of problem.
* This is a problem that someone thinks you might not want to 
catch when you write `catch (Exception)`, even if it can't be 
thrown from many places and it wouldn't kill most programs.

As an example of the former: I have a service that uses 
length-prefixed messages on raw sockets. Someone tries to connect 
to this service with curl. The length of the message is read as 
0x4854_5450_2131_2E31 -- ASCII "HTTP/1.1" as an unsigned long.

(Or we read a 32-bit length, but we're running on a system with 
128MB of RAM and overcommit turned off.)

The program might be in an invalid state if this allocation 
fails. It might not. This depends entirely on how it was written. 
The runtime is in a valid state. But the exception is 
OutOfRangeError, which inherits from Error.

Similarly, RangeError. There's little conceptual difference 
between `try {} catch (RangeError) break` and `if (i >= length) 
break`. But forbidding dynamic array indexing in nothrow code 
would be rather extreme.

On the other hand, a Unicode decoding error is a 
UnicodeException, not a UnicodeError. I guess whoever wrote that 
thought invalid Unicode data was sufficiently more common than 
invalid values in length-prefixed data formats to produce a 
difference in kind. This isn't obviously wrong, but it does look 
like something that could use justification.