Hi,
Another two cents here.
- Skipping binding a parameter to the exception would make debugging
harder. When you're stepping through code that isn't working correctly to
find a problem and then it throws an Exception which is caught in catch
block that doesn't name it e.g.
try
{
$connection = $this->connectToServer();
$data = $this->prepareData();
// lots more lines
// of code
$response = $this->getResponse();
$connection->close();
}
catch (UnexpectedException)
{
$this->retry(3);//breakpoint here, how to inspect Exception?
}
You can't actually inspect the caught exception, unless you knew where it
was going to be caught ahead of time, and went in to modify the code to
name the Exception before you started debugging.
-
The RFC says "Runtime needs to perform less checks." - I'm not an expert
on the performance cost of Exceptions but surely that must be irrelevant?
Exceptions should only happen in exceptional circumstances, so shaving a
couple of cycles from code that rarely gets called should not be a factor
in deciding this RFC. -
Throwing and catching raw \Exception classes is in general a bad pattern
and should only be rarely done, to avoid uncaught errors being shown to
end-users. It's a common anti-pattern for junior developers to catch (and
throw) \Exception rather than extending specific Exception classes for the
specific Exception that could occur.
I don't think we should be making it be the easier choice to write bad code
than to write good code.
I also don't think that it's a problem for someone coming from another
language to learn what the root Exception class is for a language. It's not
as if it's an obscure, hardly used part of the language - it's really quite
important.
Although not having to write the Exception type would make it easier for
some programmers to learn PHP, for people learning PHP as their first
language or people coming from other languages where the Exception type has
to be set, having the Exception type be optional would be one more thing to
learn.
Joost Koehoorn wrote:
"the type of an exception mostly tells enough about what happened"
I think that's only true when it's an 'expected' exception, e.g. the
ConnectionLostException from the RFC, where you almost always just want to
retry the operation.
When it's an unexpected exception e.g. caused by trying to read a corrupted
file, you almost always need to have at least log the message and in some
cases it is necessary to have additional information that can be presented
to the user in a nice format, rather than just the raw message itself. e.g.
class InsufficientCreditsException extends \Exception {
protected $creditsRequired;
public function __construct($creditsRequired, $message = null, $code =
0, Exception $previous = null){...}
}
allows an InsufficientCreditsException exception to bubble up from the call
to the external API all the way to the UI where '$creditsRequired' is
formatted nicely for the user.
Although with the RFC you could have each style of catch statement where
needed, having two different ways of writing catch statements would be
confusing when it doesn't need to be.
In summary, although this would make PHP easier to learn for a few people,
I think it makes debugging and writing good consistent code be harder, as
well as making PHP harder to learn for other people.
cheers
Dan