use PEAR::isError()
| From: | Lukas Smith | Date: | Fri, 04 Feb 2005 19:26:08 +0000 |
| Subject: | use PEAR::isError() | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-35945@lists.php.net to get a copy of this message | ||
Hi,
I keep seeing code like
if(DB::isError($foo)) {
..
}
I strongly recommend against using package specific isError() calls over the more generic PEAR::isError() check unless you are specific only interested in DB specific errors. I have been guilty of this in the past as well.
Its entirely possible for any PEAR package to be refactored to return an error object of another package and this would mean that the package specific isError() call will _not_ catch that error object.
For example PEAR::DB could decide to move the DSN parser into a separate package, which implements its own error object class. In that case the error object returned by DB::connect() my actually be an instance of DB_DSNParser_Error and not DB_Error. Unless DB_DSNParser_Error was inherited from DB_Error the static method DB::isError() will not return true if an instance of DB_DSNParser_Error is passed to it. Similar things could happen for example inside HTML_* using one of the Net_* packages.
Conclusion:
Using PEAR::isError() gurantees that you catch all error objects regardless of the originating package. There are no negative drawbacks to this. Of course if you are only interested in catching package specific error objects using the package provided isError() method is more appropriate.
I think we should probably make an announcement in pear-general. I didnt want to go ahead with this myself as some of you may have further comments (maybe even just points that need clarification).
As a side note:
Provoding a custom error class for each package therefore also has the definate advantage of letting the user determine the originating package easily. Furthermore any package who wants to provide error codes needs to provide its own error class or its impossible for the user to accurately determine what error code mapping is used (as the same error code can mean different things for different packages). Furthermore extending from PEAR will allow people to use expectError() and popExpectError() to specifically supress the global error handler.
regards,
Lukas