Re: [php-49] These days, are you using Exceptions much?

From: John S.
Sent on: Tuesday, November 20, 2012 9:03 AM
I tend, personally, not to use exceptions except when something is SO BAD that I really want the page to die. (the session says you aren't an admin? DIE!)

How do I report error statii?  Well, the last place I was at, they standardized on a response_object that contained the result (data), the "success" (boolean), the "message"(text), and sometimes the "code" (shortented version of the message with some codes that are standard like: "RecordNotFound").

For myself, If it's a smaller chunk of code, I often just return an associative array with 'result', 'success' and 'message'.  But I basically never just "return $some_value;".

There are a number of cases where success may be false when you don't want to die.  For example, if you are getting something out of a table, do you need to die if it's not there?  I suggest that if it's the current user, the answer is yes.  But much of the time, it may just be that there are no comments on this particular article, so the answer is no.  But this way there is ALWAYS enough information for the calling routine to make that decision.

Sure it's a few extra bytes, but the caller knows that every call will come back with enough information for them to be able to make proper decisions and continue.

Now, if it's an object thats being returned, then these things can be "part of" that object, which, really, should know it's own status, right?

I know - the argument is that you shouldn't continue when there are errors, and if you don't use exceptions, your code will become a huge pile of "did this succeed?", but I seem to like that style of code for the most part.  Mostly, I like that this gives me a LOT of control over the error message that is ultimately returned, and so I know what to return to the UI, so if something REALLY deep breaks, I don't have to report a message thats way out of touch with what the user is trying to do.   Maybe this is just "old school", and I'm out of date and out of touch.

One way to prevent some of the morass of checking is to select a naming convention for routines to differentiate between an "internal call" which can do some unit of work, and an external call, which can be made thru the api or by some mechanism that includes user data, that way the external ones validate the data and security, and then call the appropriate internal ones.  Then if another chunk of code needs that internal unit of work, it can call it directly, and you don't need to worry about it going thru validation, etc all over again.


   John.

===================================================================

Subject: These days, are you using Exceptions much?

From: David Malouf

Date: November 19,[masked]:37 PM

Reply to sender   Reply to Meetup

I asked some variant of this question in August, 2010... I've grown a bit as a programmer since then :-)  Including, but not limited to, the various MVC-ish approaches (most of which use an initial object [controller, director, etc.] that can include try/catch).
But I've also seen some writings on how resource-heavy exceptions are.
So I'm back to asking: do you use Exceptions or just error handling/checking in Live/Production settings (or perhaps there are other alternatives I am unaware of)?


Just curious,David Malouf

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy