Re: Proposal to differentiate between program and processing(precondition) errors

[John Locke <..hidden..>]

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 
Javascript.


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 
resume processing?

Cheers,
John
http://www.freelok.com


------------------------------------------------------------------------------
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
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel