Program logic bugs vs input/environmental errors

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Sun Sep 28 17:47:56 PDT 2014


On 9/28/2014 4:18 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> I don't follow this point.  How can this approach work with programs that are
> built with the -release switch?

All -release does is not generate code for assert()s. To leave the asserts in, 
do not use -release. If you still want the asserts to be in even with -release,

     if (condition) assert(0);


> Moreover, Sean's points here are absolutely on the money -- there are cases
> where the "users" of a program may indeed want to see traces even for
> anticipated errors.
> And even if you design a nice structure of throwing and
> catching exceptions so that the simple error message _always_ gives good enough
> context to understand what went wrong, you still have the other issue that Sean
> raised -- of an exception accidentally escaping its intended scope, because you
> forgot to handle it -- when a trace may be extremely useful.
>
> Put it another way -- I think you make a good case that stack traces for
> exceptions should be turned off by default (possibly just in -release mode?),
> but if that happens I think there's also a good case for a build flag that
> ensures stack traces _are_ shown for Exceptions as well as Errors.

The -g switch should take care of that. It's what I use when I need a stack 
trace, as there are many ways a program can fail (not just Errors).



More information about the Digitalmars-d mailing list