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