Req #69530 [NEW]: A couple of suggestions about new PHP7 exceptions hierarchy

From: Date: Sat, 25 Apr 2015 00:31:37 +0000
Subject: Req #69530 [NEW]: A couple of suggestions about new PHP7 exceptions hierarchy
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-192335@lists.php.net to get a copy of this message
From: youwish dot spambot at example dot org Operating system: PHP version: Irrelevant Package: *General Issues Bug Type: Feature/Change Request Bug description:A couple of suggestions about new PHP7 exceptions hierarchy 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 -- Edit bug report at https://bugs.php.net/bug.php?id=69530&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=69530&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=69530&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=69530&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=69530&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=69530&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=69530&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=69530&r=needscript Try newer version: https://bugs.php.net/fix.php?id=69530&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=69530&r=support Expected behavior: https://bugs.php.net/fix.php?id=69530&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=69530&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=69530&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=69530&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=69530&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=69530&r=dst IIS Stability: https://bugs.php.net/fix.php?id=69530&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=69530&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=69530&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=69530&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=69530&r=mysqlcfg

« previous php.bugs (#192335) next »