Graceful Failure
I've been thinking lately about the semantics of graceful failure.
If your software is customer-facing, you don't want an internal error to cause it to spew internal details at the consternated user. That is, among other things, a security flaw. But, at the extreme other end, you don't want it to be pretend that everything is hunky-dory when it isn't. It shouldn't say that a transaction completed when it didn't, and it shouldn't pretend that no results were found when it couldn't successfully complete the call to retrieve them.
If you are designing a web service, and the service does not convey error messages to the user, what should it convey when it is unable (due to internal error) to complete its business? I would have voted for null, but for Get-type actions, null is sometimes used to mean, "Nothing found" which is not the same thing.
Perhaps having the web service throw an error for the user to handle *is* the best solution.
If your software is customer-facing, you don't want an internal error to cause it to spew internal details at the consternated user. That is, among other things, a security flaw. But, at the extreme other end, you don't want it to be pretend that everything is hunky-dory when it isn't. It shouldn't say that a transaction completed when it didn't, and it shouldn't pretend that no results were found when it couldn't successfully complete the call to retrieve them.
If you are designing a web service, and the service does not convey error messages to the user, what should it convey when it is unable (due to internal error) to complete its business? I would have voted for null, but for Get-type actions, null is sometimes used to mean, "Nothing found" which is not the same thing.
Perhaps having the web service throw an error for the user to handle *is* the best solution.
posted by Ann at 7:13 PM
4 Comments:
Don't return an error ... return an "Explanation" ... let the consumer take it from there. It should be enumerated so the consumer can act on it. My opinion.
Hmm. I suppose if you return an XML document, the document can have whatever format you need for the occasion, including just a result code wrapped in a tag. (Indeed, I've worked with services that did it that way. You had to check the result code before you attempted to extract any data.)
Thanks for the comment! (And how cool that you have your own software company!)
Per http://stackoverflow.com/questions/175532/return-null-or-throw-exception
If it's a server side error like you said, I would return a "general server error" to the client and possible contact information for support on the error, but make sure to do something important with it on the server side. Probably log error/fatal status which probably notifies someone in QA/Dev anyways.
Returning null means I couldn't find anything to me. Abuse soap faults IMO. Most modern web service clients and languages support converting to an exception on the client side (which they should be prepared to handle anyways when communicating with an external source)
Thanks for the link!
Post a Comment
<< Home