Program logic bugs vs input/environmental errors

[Walter Bright via Digitalmars-d]

On 9/28/2014 9:16 AM, Sean Kelly wrote:
> On Sunday, 28 September 2014 at 00:40:26 UTC, Walter Bright wrote:
>>
>> Whoa, Camel! You're again thinking of Exceptions as a debugging tool.
>
> They can be.

Of course they can be. But it's inappropriate to use them that way, and we 
should not be eschewing such in the library.

> What if an API you're using throws an exception you didn't expect,
> and therefore don't handle?

Then the app user sees the error message. This is one of the cool things about D 
- I can write small apps with NO error handling logic in it, and I still get 
appropriate and friendly messages when things go wrong like missing files.

That is, until recently, when I get a bunch of debug stack traces and internal 
file/line messages, which are of no use at all to an app user and look awful.

> This might be considered a logic error if the
> exception is recoverable and you don't intend the program to abort from that
> operation.

Adding file/line to all exceptions implies that they are all bugs, and 
encourages them to be thought of as bugs and debugging tools, when they are NOT. 
Exceptions are for:

1. enabling recovery from input/environmental errors
2. reporting input/environmental errors to the app user
3. making input/environmental errors not ignorable by default

They are not for detecting logic errors. Assert is designed for that.