-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exception class cleanup #5
Comments
+1, the error level can be also handled inside of one class. Less is more ;-) |
Not quite, the more exceptions, the more possibilities to catch just the exceptions one wants to catch. |
You could do this: class LitotexException extends Exception {
const ERROR = 2;
const WARNING = 1;
private $_type;
public function __construct($message, $type = self::WARNING) {
// ...
}
public function getType() {
return $this->_type;
}
}
throw new LitotexException('some message', LitotexException::ERROR);
if ($e->getType() == LitotexException::ERROR) {
echo 'It is an error!';
} |
But the way Exceptions should be used is a lot more intuitive. ( http://www.php.net/~helly/php/ext/spl/classException.html is a good Exceptions structure, maybe a little overhead. I will try to find better solutions later.) |
+1
That's a good compromise.
|
lttxError can replace %s and similar in language strings. |
Do we really need so many Exception classes? Can we merge (or even delete) some of them?
Due to #1 and #3 we have to additionally split them into separate files, so it's good if we don't have so many classes.
The text was updated successfully, but these errors were encountered: