Question

So after much debate back and forth, I’ve come up with what I think may be a valid plan to handle Application/System errors vs User Errors (I.e. Validation Issues, Permission Issues etc).

Application/System Errors will be handled using a custom error handler (via set_error_handler()). Depending on the severity of the error, the user may be redirected to a generic error page (I.e. Fatal Error), or the error may simply be silently logged (i.e E_WARNING).

These errors are ones most likely caused by issues outside the users control (Missing file, Bad logic, etc).

The second set of errors would be User Generated ones. These are the ones may not automatically trigger an error but would be considered one. In these cases i”ve decided to use the trigger_error() function and typically throw a waning or notice which would be logged silently by the error handler. After that it would be up to the developer to then redirect the user to another page or display some sort of more meaningful message to the user.

This way an error of any type is always logged, but user errors still allow the developer freedom to handle it in their own ways. I.e. Redirect them back to their form with it fully repopulated and a message of what went wrong.

Does anyone see anything wrong with this, or have a more intuitive way? My approach to error handling is typically everyone has their own ways but there must be a way instituted.

Answer 1

I really prefer exceptions over old-fashion error handling. The advantages include:

• You can delay error handling: there’s no need to take a decision (stop or continue, display message or log) in the very moment the error happens. That allows cleaner code and cleaner output (you can’t always print a message when you are doing an fopen call).

• You can group similar errors and unify its handling. E.g.: when you read a file there’re many possible error conditions, you don’t really need to consider them all individually.

• You can create custom exceptions for those error conditions you describe that are part of the normal workflow; compare UserNotAllowedException to E_USER_ERROR.

There’re also some tricks to convert regular errors to exceptions.