Program logic bugs vs input/environmental errors

Joseph Rushton Wakeling via Digitalmars-d digitalmars-d at puremagic.com
Sun Sep 28 16:18:02 PDT 2014


On 28/09/14 19:33, Walter Bright via Digitalmars-d wrote:
> On 9/28/2014 9:23 AM, Sean Kelly wrote:
>> Also, I think the idea that a program is created and shipped to an end user is
>> overly simplistic.  In the server/cloud programming world, when an error occurs,
>> the client who submitted the request will get a response appropriate for them
>> and the system will also generate log information intended for people working on
>> the system.  So things like stack traces and assertion failure information is
>> useful even for production software.  Same with any critical system, as I'm sure
>> you're aware.  The systems are designed to handle failures in specific ways, but
>> they also have to leave a breadcrumb trail so the underlying problem can be
>> diagnosed and fixed.  Internal testing is never perfect, and achieving a high
>> coverage percentage is nearly impossible if the system wasn't designed from the
>> ground up to be testable in such a way (mock frameworks and such).
>
> Then use assert(). That's just what it's for.

I don't follow this point.  How can this approach work with programs that are 
built with the -release switch?

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.


More information about the Digitalmars-d mailing list