|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2016-09-15 14:14 UTC] cmb@php.net
-Status: Open
+Status: Closed
-Assigned To:
+Assigned To: cmb
[2016-09-15 14:14 UTC] cmb@php.net
|
|||||||||||||||||||||||||||
Copyright © 2001-2026 The PHP GroupAll rights reserved. |
Last updated: Sat Apr 18 13:00:01 2026 UTC |
Description: ------------ Since basically all languages failed to have a decent exception hierarchy, let's try to not do the same with PHP7. First of all some short definitions: "unchecked": errors that SHOULD (usually) NOT BE handled to offer equivalent functionality "checked": errors that SHOULD (usually) BE handled to offer equivalent functionality Not saying that PHP should have exceptions in signatures, I'm using these names just for clarity. What's most important, is to have a correct hierarchy. I'd start considering Exception the base class for "checked" exceptions. That's how people use it today, since PHP didn't have anything like "unchecked" exceptions so far. Currently the exception hierarchy is: BaseException (abstract) +- EngineException +- TypeException +- ParseException +- Exception +- AssertionException How it should be: Throwable (was BaseException, abstract) +- Error (was EngineException, unclassified errors) +- TypeCheckError (was TypeException) +- AssertionError (was AssertionException) +- ParseError (was ParseException) +- Exception So, firstly I don't think it's correct to have AssertionException caught by catch(\Exception $e) blocks. When one uses a catch(\Exception $e), an alternative implementation is being provided for anything that could have caused an error in the try{} block **while in production**. When an assert() fails, instead, the developer wants to be informed of the error, rather than executing the code that handles it and that hides what was the expectation / the actual problem. So I would move that from under Exception. ParseException is a bit tougher to classify but I believe it's better placed under EngineException since it is an error type that unlikely is going to be handled but rather just logged / debugged. It works fine with siblings and parent since you can easily differentiate using properly ordered catch() blocks: /* siblings */ catch(ParseError $a){} /* siblings */ catch(TypeCheckError $b){} /* siblings */ catch(AssertionError $c){} catch(Error $c){} A more complete, future, exception bundle could be: Throwable +- Error +- TypeError +- NullPointerError +- TypeCheckError +- TypeCastError (like array to string) +- AssertionError +- ParseError +- InclusionParseError +- EvaluationError +- MathError +- DivisionByZeroError +- NaNError +- Exception HTH