Program logic bugs vs input/environmental errors

[Steven Schveighoffer via Digitalmars-d]

On 9/29/14 2:43 PM, Jeremy Powers via Digitalmars-d wrote:
> On Mon, Sep 29, 2014 at 8:13 AM, Steven Schveighoffer via Digitalmars-d
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
>
>     My entire point is, it doesn't matter what is expected or what is
>     treated as "correct." what matters is where the input CAME from. To
>     a library function, it has no idea. There is no extra type info
>     saying "this parameter comes from user input."
>
>
>  From the method's view, parameters passed in are user input.  Full stop.

This is missing the point of an exception. An uncaught exception is an 
error which crashes the program. If you catch the exception, you can 
handle it, but if you don't expect it, then it's a bug. Any uncaught 
exceptions are BY DEFINITION programming errors.

> One thing that seems to be talked around a bit here is the
> separation/encapsulation of things.  It is perfectly fine, and expected,
> for a library method to throw exceptions on bad input to the method -
> even if this input turns out to be a programming bug elsewhere.  From
> the standpoint of the method, it does not know (and does not care) where
> the thing ultimately came from - all it knows is that it is input here,
> and it is wrong.

What is being discussed here is removing the stack trace and printout 
when an exception is thrown.

Imagine this error message:

myprompt> ./mycoolprogram
(1 hour later)
FileException: Error opening file xgghfsnbuer
myprompt>

Now what? xgghfsnbuer may not even be in the code anywhere. There may be 
no hints at all as to what caused it to happen. You don't even know 
which line of code YOU wrote that was causing the issue! You have to 
examine every File open, and every call that may have opened a file, and 
see if possibly that file name was passed into it.

Whereas if you get a trace, you can at least see where the exception 
occurred, and start from there.

Now, RELYING on this printout to be your interface to the user, that is 
incorrect design, I will agree. But one cannot possibly be expected to 
handle every possible exception at every possible call so one can throw 
an error in the cases where it actually is an error. D doesn't even 
require listing the exceptions that may be thrown on the API (and no, 
I'm not suggesting it should).

> If you call a method with bad input, and fail to catch the resulting
> exception, then _that_ is a bug, not the method throwing.  It may be
> perfectly recoverable to ignore/retry/whatever, or it may be a symptom
> of something that should abort the program.  But the method throwing
> does not know or care.
>

Sure, but it doesn't happen. Just like people do not check return values 
from syscalls.

The benefit of the exception printing is at least you get a trace of 
where things went wrong when you didn't expect them to. Ignoring a 
call's return value doesn't give any notion something is wrong until 
much later.

-Steve