Home | Photography | Flickr | LiveJournal | Get Firefox

PHP has set_error_handler(), trigger_error() and friends. But they aren't exactly up to par for handling massively abstracted code. So… how do you handle errors? Here's an example. It's overly complicated for something so simple, but… that's because it's merely a simple example.

Imagine you have a block of PHP code like this:

$res = add_two_numbers(15,27);
print $res;

Now let's look at the add_two_numbers() function:

function add_two_numbers($a,$b) {

$calc = start_super_number_calculator();

add_number_to_stack($calc, $a);
add_number_to_stack($calc, $b);
perform_operation_on_stack($calc, 'add');
$result = get_number_from_stack($calc);

return $result;

}

I won't bore you with the code for the "super_number_calculator". However, let's look at the above function. What happens if, for what ever reason, start_super_number_calculator() has an error. In the above case we could test to see if $calc was a valid calculator resource identifier, and, if it wasn't, we could return an error. But how would we return that error? We could return false;. But, what if we want to know WHY there was an error? We could use trigger_error() and an error handler to trap the error and obtain additional information. But, since you can only define one error handler at a time, you'll have no way of knowing whether that error message should be displayed to the user or not. Since, unless you want to code in the line numbers and file names of the various pieces of your application, you won't know exactly where the error came from… you'll have no choice but to either display all errors (of a certain type) to the user, or to not display them. That's less than ideal.

So, let's say we don't want to know why there is an error — we just want to know that there was one. Then set_error_handler() might come in handy. However, what if, in some cases, an error is… okay… ignorable… whatever? Then set_error_handler() doesn't work. Okay… so then, back to idea number 1: well just return false; and test for that. That's great… except… what if I made a new function called is_this_a_number()? This funtion will return true or false depending on if it is a number or not. How do I know if that false that is returned means it is NOT a number… or there was an error in processing?

The only solution I can think of, and it isn't a good one, is to have all functions return an array. The first element of the array is ALWAYS either true or false. If it is true, the expected return values will be the next elements of the array. If it is false the next 2 elements will be an error number, and an error message. Unfortunately, this makes code look pretty messy.

Another option, that I don't usually employ, is to write a universal function called hey_php_you_stupid_fuck_is_this_an_error_or_not(). If there is an error in processing, a function should return a struct that contains an element named "_##_ERROR_##_". The error checking function looks for that element in the return value, and returns true if it is seen. Then, the code knows that the error message and error number are available in the struct. This means that, after every function call, instead of checking if the first element is true you run it through hey_php_you_stupid_fuck_is_this_an_error_or_not(). It accomplishes basically the same thing. However, it does so in a way that allows "legacy" functions to operate normally (without proper error reporting) without altering any code. Actually, now that I think about it, this option might actually be better than the one I currently use. But… it still isn't that great.

So… I ask again: how do you do it?

Share and Enjoy:
  • Facebook
  • StumbleUpon
  • Digg
  • e-mail
  • del.icio.us
  • Google
  • Reddit
  • Technorati
  • BlinkList
  • blogmarks
  • Blue Dot
  • description
  • Furl
  • Ma.gnolia
  • MisterWong
  • Netvouz
  • PlugIM
  • Propeller
  • Simpy
  • Spurl
  • TailRank