Program logic bugs vs input/environmental errors

[H. S. Teoh via Digitalmars-d]

On Sun, Sep 28, 2014 at 10:32:14AM -0700, Walter Bright via Digitalmars-d wrote:
> On 9/28/2014 9:16 AM, Sean Kelly wrote:
[...]
> >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.

It looks even more awful when the person who wrote the library code is
Russian, and the user speaks English, and when an uncaught exception
terminates the program, you get a completely incomprehensible message in
a language you don't know. Not much different from a line number and
filename that has no meaning for a user.

That's why I said, an uncaught exception is a BUG. The only place where
user-readable messages can be output is in a catch block where you
actually have the chance to localize the error string. But if no catch
block catches it, then by definition it's a bug, and you might as while
print some useful info with it that your users can send back to you,
rather than unhelpful bug reports of the form "the program crashed with
error message 'internal error'". Good luck finding where in the code
that is. (And no, grepping does not work -- the string 'internal error'
could have come from a system call or C library error code translated by
a generic code-to-message function, which could've been called from
*anywhere*.)


> >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.

I do not condone adding file/line to exception *messages*. Catch blocks
can print / translate those messages, which can be made user-friendly,
but if the program failed to catch an exception, you're already screwed
anyway so why not provide more info rather than less?

Unless, of course, you're suggesting that we put this around every
main() function:

	void main() {
		try {
			...
		} catch(Exception e) {
			assert(0, "Unhandled exception: I screwed up");
		}
	}


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser