Re: When throw exceptions?

[talexb]

I wrote an API about a year ago using Dancer whose methods returned two items, a result object and an application error. If the result object was undef, then the application error would be defined, and that error was passed back up the object hierarchy to be returned to the caller.

During the code review for this API, I was criticized for not implementing this as a die or croak. It's a matter of taste -- for me, this type of error was application level, and not system level; it's something that could safely be reported back to the caller. IMO, a system level error would be something catastrophic like the database connection being unavailable.

Really, it's up to you -- make a decision how you're going to design your application, and after that, just be consistent.

[sundialsvc4]

/me nods...

And I would have been one of those dissenting voices in your review committee.   If you had told me that the returned object was some kind of a status record, I might have asked why you then did not simply return one structure (like a typical JSON response structure) in which both the status and the result were part of a single record/hash.   If it were an error, and (I am not knowledgeable of Dancer) it was not a situation very much like that of a JSON response, I, too, would have advocated the throw-an-exception mechanism because of its ability to circumvent “all those tests.”   (Then I would have listened, attentively, to your counter-argument, and have been fully prepared to reverse my position in your favor.)

I entirely agree with your closing comment, however:   make a decision, and thereafter be consistent.