Exception re-throwing through layers and usage of status codes

Question

Hi all!

I searched for this for a long time (here too), have read many php codes, but still couldn't find a satisfying answer. It may seem a too wide topic, but it really sticks together - at last for me. Could you please help?

In a php website I have PDO as DAL, what is used by BLL objects, and they are called from the UI. Now if something happens, PDO throws a PDOException. Of course the UI layer doesn't have to know anything about PDOExceptions, so the BLL object catches it. But now what?

I have read that

1. exceptions are for truly exceptional situations and
2. one re-throws exceptions from lower layers in order not to get low-level exceptions in upper layers.

Let me illustrate my problem (please don't pay attention to the function args):

class User
{
 function signUp()
 {
  try
  {
   //executes a PDO query
   //returns a code/flag/string hinting the status of the sign up:
   //success, username taken, etc.
  }
  catch (PDOException $e)
  {
   //take the appropriate measure, e.g. a rollback

   //DataAccessException gets all the information (e.g. message, stack
   //trace) of PDOException, and maybe adds some other information too
   //if not, it is like a "conversion" from PDOException to DAE
   throw new DataAccessException();
  }
 }
}

//and in an upper layer
$user = new User();
try
{
 $status = $user->signUp();
 //display a message regarding the outcome of the operation
 //if it was technically successful
}
catch (DataAccessException $e)
{
 //a technical problem occurred
 //log it, and display a friendly error message
 //no other exception is thrown
}

Is this a right solution? When re-throwing the PDOException I don't think it would be appropriate to use exception chaining (as this would only make debugging information redundant; DataAccessException gets everything, including the full stack trace from PDOException).

Thanks in advance.

Answer 1

As I understood your post a good resource is this: Api design

I think that you've done your homework (if I can use the phrase) but you forgot the reason why this thing is being done. In your example I'd create something like

SignUpException

which would inform the upper layers that something has gone wrong about signup. What you do here is essentially masking a database exception with a different named one, which is essentially the same thing, something that although programmatically correct, misses the point of the why-s of doing it in the first place.