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 Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel