How should I throw exceptions in a php auth class? - php

Question

When throwing exceptions in the following auth class example is it recommended to throw a different exception for each situation to be handled, eg:
addUser(...) {
// normal database code here...
switch(TRUE) {
case ($username_exists):
throw new UserExists('Cannot create new account. Account username ' . $un . ' already exists.');
case ($email_exists):
throw new EmailExists('Cannot create new account. Account email ' . $email . ' already exists.');
}
}
//to be called externally by...
try {
$auth->adduser(...);
} catch (UserExists) {
$output = 'That username is already taken.';
} catch (EmailExists) {
$output = 'That email is already being used.';
} catch (AuthException $e) {
$output = $e->getMessage();
}
echo $output;
}
or is it recommended to throw a general "type" of exception with a unique exception code? eg...
addUser(...) {
// normal database code here...
switch(TRUE) {
case ($username_exists):
throw new AuthException('Cannot create new account. Account username ' . $un . ' already exists.', 10);
case ($email_exists):
throw new AuthException('Cannot create new account. Account email ' . $email . ' already exists.', 20);
}
}
//to be called externally by...
try {
$auth->adduser(...);
} catch (AuthException $e) {
switch($e->getCode()) {
case 10:
$output = 'That username is already taken.';
break;
case 20:
$output = 'That email is already being used.';
break;
default:
$output = $e->getMessage();
}
echo $output;
}
I ask because I'm new to exceptions and both solutions seem equally viable. Perhaps there are other solutions entirely?
Interesting side-note: I didn't realize I was asking a "what's your preference" question until after receiving a few answers. I anticipated a single recommended method.

Answer 1

I wouldn't say one way is right and one way is wrong - and asking a "is this way recommended versus this way" can easily stir up a large pot if the question hits the right nerve in a large group.
Regarding your question specifically, both are valid and acceptable ways to throw different types of exceptions - and I've seen both quite frequently.
In large-scale applications in just about every language, however, I see the bottom method more often than not - and it's also my own personal style/preference. I think that throwing a single "type" of exception, AuthException, and specifying an exception-code is very clear and concise.
If you want it to be more descriptive (from a programming standpoint), you can use an pseudo-enum* setup for the codes to give a user-friendly description:
class AuthExceptionCode {
const USER_EXISTS = 0;
const EMAIL_EXISTS= 1;
// ....
}
To throw the exception with the code:
throw new AuthException('error message', AuthExceptionCode::USER_EXISTS);
If you have an actual custom-Exception class, i.e. - you extend Exception, you can place the codes direction in the class itself:
class AuthException extends Exception {
const MISC = -1;
const USER_EXISTS = 0;
const EMAIL_EXISTS= 1;
public function __construct($message, $code = self::MISC) {
switch ($code) {
case self::USER_EXISTS:
// example on how to access the codes from within the class
// ...
* Enumerations are not native to PHP, so using const is the easiest method (without using a 3rd-party class/plugin.

Answer 2

In general, I think the best practice is that an exception should encompass a single exceptional condition. Take the SPL exceptions, for example. Would you throw InvalidUserArgumentException and InvalidEmailArgumentException? Nope. You'd throw the SPL InvalidArgumentException and just change the exception message based on the details (e.g. "Invalid user" or "Invalid email"). That said, IMHO, you should use a single AuthException and just vary the message (like you did in your 2nd example), only instead of using codes and a switch, just output the exception message directly:
try {
$auth->adduser(...);
} catch (AuthException $e) {
$output = $e->getMessage();
}
echo $output;

Answer 3

I prefer the top way where you have a separate catch statement for each exception that can occur, but it depends.. If you find yourself have really long exception class names where it's difficult to understand their meaning, then I would group them up a bit.