Program logic bugs vs input/environmental errors

[H. S. Teoh via Digitalmars-d]

On Fri, Oct 24, 2014 at 03:29:43PM -0300, Ary Borenszweig via Digitalmars-d wrote:
> On 9/27/14, 8:15 PM, Walter Bright wrote:
> >This issue comes up over and over, in various guises. I feel like
> >Yosemite Sam here:
> >
> >     https://www.youtube.com/watch?v=hBhlQgvHmQ0
> >
> >In that vein, Exceptions are for either being able to recover from
> >input/environmental errors, or report them to the user of the application.
> >
> >When I say "They are NOT for debugging programs", I mean they are NOT
> >for debugging programs.
> >
> >assert()s and contracts are for debugging programs.
> 
> Here's another +1 for exceptions.
> 
> I want to add a a slash command to Slack
> (https://slack.zendesk.com/hc/en-us/articles/201259356-Slash-Commands).
> So, for example, when I say:
> 
> /bot random phrase
> 
> This hits a web server that processes that request and returns a random
> phrase.
> 
> Now, imagine I have an assert in my application. When the web server
> hits the assertion it shuts down and the user doesn't get a response.
> What I'd like to do is to trap that assertion, tell the user that
> there's a problem, and send me an email telling me to debug it and fix
> it. That way the user can continue using the bot and I meanwhile I can
> fix the bug.
> 
> In the real world where you don't want unhappy users, asserts don't
> work.
> 
> Walter: how can you do that with an assertion triggering?

Sure they do.

Your application should be running in a separate process from the
webserver itself. The webserver receives a request and forwards it to
the application process. The application process processes the request
and sends the response back to the webserver, which forwards it back on
the client socket. Meanwhile, the webserver also monitors the
application process; if it crashes before producing a response, it steps
in and sends a HTTP 500 response to the client instead. It can also
email you about the bug, possibly with the stack trace of the crashed
application process, etc..  (And before you complain about inefficiency,
there *are* ways of eliminating copying overhead when forwarding
requests/responses between the client and the application.)

But if the webserver itself triggers an assertion, then it should NOT
attempt to send anything back to the client, because the assertion may
be indicating some kind of memory corruption or security exploit
attempt. You don't know if you might be accidentally sending sensitive
personal data (e.g. password for another user) back to the wrong client,
because your data structures got scrambled and the wrong data is
associated with the wrong client now.

Basically, if you want a component to recover from a serious problem
like a failed assertion, the recovery code should be in a *separate*
component. Otherwise, if the recovery code is within the failing
component, you have no way to know if the recovery code itself has been
compromised, and trusting that it will do the right thing is very
dangerous (and is what often leads to nasty security exploits). The
watcher must be separate from the watched, otherwise how can you trust
the watcher?


T

-- 
Why ask rhetorical questions? -- JC