[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Just to add to this for sake of discussion

First, for history's sake, we inherited the undifferentiated error case from sql-ledger.  We have actually started decoupling htis in some ways but that is very far from complete.  Discussion and thoughts on this matter are very welcome.

On Sun, Jun 21, 2015 at 1:41 PM, Erik Huelsmann <..hidden..> 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".

Yeah, we could do a  better job of handling this. 

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!

It can include the stack trace.  I don't think we do by default though with Starman you can turn this on and off by using -MCarp::Always but if this is happening without, it is a bug.

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.

Agreed.  We should also use the required field in html as well. 

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.

Agreed here too. 

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

 Ok, so currently we have a couple mechanisms we could use for this.

1)  On the HTML side we really should set the required attribute where appropriate.  As a bonus we can use css to highlight what is required.
2)  On the server/service side, we now have LedgerSMB/Request.pm which allows us to specify required fields.  We could modify that and the global error handling, to allow http statuses to be included.  Remember we can die $hashref, and intercept/handle variables on that hashref.  I could probably have a patch in to route from the required functions there to have appropriate http statuses fairly quickly.

Best Wishes,
Chris Travers



http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.
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