On 10/3/14 1:40 PM, Sean Kelly wrote:
Setting aside exceptions for the moment, one thing I've realized about
errors is that in most cases, an API has no idea how important its
proper function is to the application writer.
This is the thing I have been arguing. Inside a library, the idea of
input to the function being user defined or program-defined is not
clear. It means that any user-defined input has to be double checked in
the same exact way, to avoid having an error thrown in the case that the
library function throws an error on such input. The other side, any
program-caused errors that end up triggering exceptions (a misnamed
filename for opening a config file, for instance), needs to treat this
exception as an error and halt the program with an appropriate stack trace.
What makes sense to me is:
1. If you send in an obvious programming error (i.e. null instead of an
expected target address), throw an error. This can be done in contract
precondition scopes. Such things could NOT be generated by user.
2. If you send in something that doesn't make sense, but could be
user-generated, throw an exception. User-generated is a very fuzzy
thing, but we should conservatively assume the input is user-generated.
3. If anything happens internally to the function, treat it as an error.
If an input causes an exception, but the input was program generated,
don't catch it in the calling scope! Just let the runtime handle it as
an error, and exit the program. Any uncaught exceptions should be
treated as errors anyway.
It might be a good idea to have an umbrella exception type that means
"input invalid." This gives some easy way to catch all such exceptions
and print them properly in the case where it's user-defined input.
-Steve
