Program logic bugs vs input/environmental errors

Marco Leise via Digitalmars-d digitalmars-d at puremagic.com
Wed Oct 1 05:14:15 PDT 2014


Am Sun, 28 Sep 2014 13:14:43 -0700
schrieb Walter Bright <newshound2 at digitalmars.com>:

> On 9/28/2014 12:33 PM, Jacob Carlborg wrote:
> > On 2014-09-28 19:36, Walter Bright wrote:
> >
> >> I suggest removal of stack trace for exceptions, but leaving them in for
> >> asserts.
> >
> > If you don't like the stack track, just wrap the "main" function in a try-catch
> > block, catch all exceptions and print the error message.
> 
> That's what the runtime that calls main() is supposed to do.

Guys, a druntime flag could settle matters in 10 minutes.
But this topic is clearly about the right school of thought.

I use contracts to check for logical errors, like when an
argument must not be null or a value less than the length of
some data structure.
I use exceptions to check for invalid input and the return
values of external libraries. External libraries can be
anything from my own code in the same project to OpenGL from
vendor XY. They could error out on valid input (if we leave
out of memory aside for now), because of bugs or incorrect
assumptions of the implementation.
If that happens and all I get is:
"Library XY Exception: code 0x13533939 (Invalid argument)."
I'm at a loss, where the library might have had a hickup.
Did some function internally handle a uint as an int and
wrapped around?
Maybe with std.logger we will see single line messages on the
terminal and multi-line exception traces in the logs (which by
default print to stderr as well). And then this discussion can
be resolved.

-- 
Marco



More information about the Digitalmars-d mailing list