Zend Framework: Zend_Exception Component Proposal
| Proposed Component Name | Zend_Exception |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Exception |
| Proposers | Aleksey V. Zapparov |
| Revision | 1.1 - 24 December 2007: First release of the proposal. 1.2 - 01 January 2008: Prepared for review. 1.2 - 21 June 2008: Ready for review. (wiki revision: 14) |
Table of Contents
1. Overview
Today Zend_Exception extends SPL's Exception class, which has not very much of info. Instead of this I propose to extend ErrorException, so Zend_Exception can be used as set_error_handler() handler.
2. References
- SPL-StandardPHPLibrary: Exception Class Reference
- SPL for the masses
- PHP man page: set_error_handler()
- PHP man page: restore_error_handler()
- ErrorException Class Info
3. Component Requirements, Constraints, and Acceptance Criteria
4. Dependencies on Other Framework Components
5. Theory of Operation
This proposal will allow to handle errors just like exceptions.
The purpose of this modification is to use Zend_Exception as an error to exception convertor.
6. Milestones / Tasks
7. Class Index
- Zend_Exception
16 Comments
comments.show.hideDec 26, 2007
Lars Strojny
I would propose not to use create_function() but a static function Zend_Exception::handleError() which handles as the error handler. Except that this seems to be a great proposal.
Dec 27, 2007
Aleksey V. Zapparov
I have didn't thounght about it. I agree that static function Zend_Exception::handleError() will be much better. I'll update skeleton according to your suggestion.
Jan 24, 2008
Geoffrey Tran
I don't think it should be placed under Zend_Exception, but rather Zend_Error because an error handling system could be developed more flexible that way. Restricting it to Zend_Exception would not be ideal.
Jan 24, 2008
Simon Mundy
I'd like to see the ability to pass severity levels to the handleErrors method to allow more fine-grained control
E.g. handleErrors($severity = E_ALL)
So you could potentially pass Zend_Exception::handleErrors(E_ALL & ~E_NOTICE | E_WARNING);
I can't see the point in a Zend_Error component - if you wished to handle errors in a more specific way you'd no doubt be creating your own classes to deal with that?
Jan 26, 2008
Aleksey V. Zapparov
Thank you for your notice about severity level.
I've just forgot about this optional argument of set_error_handler() function. I agree that this is necesary ability.
Added this ability, but called it $error_types (not $severity) just for "backward compability" with manual. I agree that $severity is maybe much better name for this param, but imho it's much better to give the same name as in PHP manual. I'm judging by myself - I always have PHP manual opened when I'm coding, so it take less time to understand what one thing (or wraper) is doing if arguments have the same names as in manual. If you think else, please let me know.
Jan 26, 2008
Aleksey V. Zapparov
I don't think that it has to be placed into independet class such as Zend_Error, just because Zend_Exception is the "core" of error handling in framework and this proposal is just makng Zend_Exception able to serve almost all errors happened in application.
But in other hand, I think there is a place for Zend_Error class, just in the role of decorator. So it can be used to handle exceptions in common way or something like this. But, as Simon noticed: "if you wished to handle errors in a more specific way you'd no doubt be creating your own classes to deal with that". So IMHO even if there will be Zend_Error it will be just a wraper to do tricks with exceptions and errors.
May 13, 2008
Wil Sinclair
Alexsey, is this proposal ready for community review?
,Wil
May 21, 2008
Aleksey V. Zapparov
Hello, Wil.
Yes. This proposal is ready for review.
Jun 20, 2008
Wil Sinclair
You should put this in to the 'Ready for Review' section and announce that it is ready for review on the general mailing list. Please see the new proposal process docs.
,Wil
Jun 21, 2008
Matthew Ratzloff
Note that in its current form this proposal is incompatible with the built-in translation functionality of Exception codes in exceptions - Matthew Ratzloff & Thomas Weidner.
Jun 22, 2008
Aleksey V. Zapparov
I disagree. I don't see any problems here. It's totally compatible, except only that it take severity level in constructor.
So for example, here's almost mixed (and probably buggy) version of your proposals (with my fixes which I have commented on proposal's page) and mine:
Anyway, even with some of my fixes it still has bugs. And even with respect to that proposal is older then this, it has to be fixed. And maybe it's better to apply that proposal over this. Or return to talks about this proposal's incompatability with that proposal, when that proposal will be at least in incubator (so it will have no bugs).
When I'm saying about bugs I mean for example:
In this method you are expecting to get an integer of Exception code as a return value, but you'll get boolean true if $this->_getConstant($exceptionName) equal to $this->code, and false otherwise.
Jun 22, 2008
Thomas Weidner
Wouldn't it be problematic if someone is already using his own error_handler ?
You can only set one error_handler at once.
Wouldn't it be better to have exceptions and errors seperated ?
An exception can be handled by the application.
An error would need a completly different usage to be handled.
Also as already mentioned, the output can not be translated so all logs must be in english which does not take in account all non-native english people.
Jun 22, 2008
Aleksey V. Zapparov
This proposal not forces anybody to use this error_handler.
So if somebody have it's own error handler - he just have not to call Zend_Exception::setErrorHandler() method.
And yes if somebody want to have exceptions and errors separated - he can. But for me, for example, it's better to use everything as exceptions, so I can handle all of it in one place.
Jun 22, 2008
Aleksey V. Zapparov
I was thinking about what Thomas Weidner said about "separating flies from cutlets" and idea stikes me.
The best way is to separate this proposal to Zend_Exception_Error
So one part (constructor for example) of this proposal will migrate to Zend_Exception_Error
and another part (static methods of setting error_handler) will stay in Zend_Exception.
This way will help to integrate this proposal into current structure easily and without any additional modifications (So integration with Exception codes in exceptions - Matthew Ratzloff & Thomas Weidner will become transparent).
)
Jun 22, 2008
Nico Edtinger
Shouldn't the default value for $error_types only contain errors (E_USER_ERROR and E_RECOVERABLE_ERROR)? Everything else is not really an error and shouldn't even happen in deployed code.
Feb 07, 2011
Dolf Schimmel (Freeaqingme)
Archiving this proposal, feel free to recover it when you want to work on it again. For more details see this email.