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.
