Program logic bugs vs input/environmental errors

[Cliff via Digitalmars-d]

On Sunday, 28 September 2014 at 20:58:20 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> 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");
> 		}
> 	}
>

In our production C# code, we had a few practices which might be 
applicable here:

1. main() definitely had a top-level try/catch handler to produce 
useful output messages.  Because throwing an uncaught exception 
out to the user *is* a bug, we naturally want to not just toss 
out a stack trace but information on what to do with it should a 
user encounter it.  Even better if there is additional runtime 
information which can be provided for a bug report.

2. We also registered a top-level unhandled exception handler on 
the AppDomain (equivalent to a process in .NET, except that 
multiple AppDomains may exist within a single OS process), which 
allows the catching to exceptions which would otherwise escape 
background threads.  Depending on the nature of the application, 
these could be logged to some repository to which the user could 
be directed.  It's hard to strictly automate this because exactly 
what you can do with an exception which escapes a thread will be 
application dependent.  In our case, these exceptions were 
considered bugs, were considered to be unrecoverable and resulted 
in a program abort with a user message indicating where to find 
the relevant log outputs and how to contact us.

3. For some cases, throwing an exception would also trigger an 
application dump suitable for post-mortem debugging from the 
point the exception was about to be thrown.  This functionality 
is, of course, OS-specific, but helped us on more than a few 
occasions by eliminating the need to try to pre-determine which 
information was important and which was not so the exception 
could be usefully populated.

I'm not a fan of eliminating the stack from exceptions.  While 
exceptions should not be used to catch logic errors, an uncaught 
exception is itself a logic error (that is, one has omitted some 
required conditions in their code) and thus the context of the 
error needs to be made available somehow.