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