[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal to differentiate between program and processing(precondition) errors
- Subject: Re: Proposal to differentiate between program and processing(precondition) errors
- From: John Locke <..hidden..>
- Date: Sun, 21 Jun 2015 22:29:15 -0700
One more time!
On 06/21/2015 01:41 PM, Erik Huelsmann wrote:
> Currently, all errors generated by LedgerSMB are being raised through
> 'die'. It's an effective way, but my feeling is that it bleeds through
> too many details of the internals. This is especially true when the
> error is really nothing more than a reported "missing configuration".
> E.g. we currently generate an error in case there's a field's value
> missing. The generated error includes a stack dump and all!
This does seem absurd at this point -- why not just change those to
throw exceptions? Then we can catch them at the appropriate point and
bubble those up to the interface.
> My proposal is that in this type of error case, we're checking the
> existence of the required fields and their values. If these don't
> exist, we should be reporting a nicely formatted error to the client
> -- most definitely without a stack trace.
> Also, the HTTP status code for each error-with-stacktrace is currently
> "500" -- Internal Server Error. When we *understand* the request, but
> can't process it, we should be generating a 422 (Unprocessable entity)
> response or alike.
> Now for the question: what would be the best way to achieve this? (I
> think this applies equally to HTML page responses as it does to web
> service api calls, so this is a general question that needs a general
> solution which is applicable for a long time.)
Exceptions. Without question.
We do need separate response objects that get instantiated right at the
start of the request. These should have some sort of ending method --
something like ->send() -- to actually output the response back to the
requestor, in the appropriate format.
Server side, we need a global exception handler to catch anything not
caught during actual processing, which can attach the appropriate error
data to the response header along with the appropriate error code. The
response object should generally return an appropriate http response
code, and can then pass the stack trace (if appropriate) and any other
data necessary, on up to the browser.
The response object should be smart enough to know how much detail to
transmit -- perhaps some other service can filter messages if we want to
keep very sensitive stuff away from the browser, and only transmit it
all if the site is set to 'debug'...
So really what I've described so far is how to get an exception up to
the browser. We haven't really handled it, just transmitted it. If we're
going single page, we really need to handle that in the browser, so most
of the actual graceful handling of the exceptions will end up being
I think one area we might want to explore further is what kinds of
exceptions we want to handle, where. Do we need specialized exception
classes? Do we catch some kinds of exceptions and simply log them, then
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical & virtual servers, alerts via email & sms
for fault. Monitor 25 devices for free with no restriction. Download now
Ledger-smb-devel mailing list