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.
