Hi,
Attached is a patch (+ 2 files) that add a default "exception" class to
Zend 2. I find this very useful when you just want to throw a simple
exception inside of a try {}, but you don't want to create a new
exception for each and every error. I'll commit this tommorowish,
unless somebody objects.
-Sterling
"Whether you think you can or think you can't -- you are right."
- Henry Ford
Hi,
As per naming convention, I think it'd be nice if the methods were
named as:
getmessage => get_message
getcode => get_code
If those are corrected, +1 for this feature.
Moriyoshi
Sterling Hughes sterling@bumblebury.com wrote:
Hi,
Attached is a patch (+ 2 files) that add a default "exception" class to
Zend 2. I find this very useful when you just want to throw a simple
exception inside of a try {}, but you don't want to create a new
exception for each and every error. I'll commit this tommorowish,
unless somebody objects.-Sterling
"Whether you think you can or think you can't -- you are right."
- Henry Ford
Hi,
As per naming convention, I think it'd be nice if the methods were
named as:getmessage => get_message
getcode => get_codeIf those are corrected, +1 for this feature.
I was thinking of that - I would personally prefer get_message() and
get_code() naming, but that goes against pear's naming conventions, and
I want this to integrate well with pear (as a base class.)
-Sterling
Moriyoshi
Sterling Hughes sterling@bumblebury.com wrote:
Hi,
Attached is a patch (+ 2 files) that add a default "exception" class to
Zend 2. I find this very useful when you just want to throw a simple
exception inside of a try {}, but you don't want to create a new
exception for each and every error. I'll commit this tommorowish,
unless somebody objects.-Sterling
"Whether you think you can or think you can't -- you are right."
- Henry Ford
--
"People can have the Model T in any colour -- so long as it's black."
- Henry Ford
Hi,
As per naming convention, I think it'd be nice if the methods were
named as:getmessage => get_message
getcode => get_codeIf those are corrected, +1 for this feature.
I was thinking of that - I would personally prefer get_message() and
get_code() naming, but that goes against pear's naming conventions, and
I want this to integrate well with pear (as a base class.)
It's a PHP function, not PEAR code, so it should follow the PHP naming
style.
Derick
--
"my other box is your windows PC"
Derick Rethans http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals http://php-mag.net/
Hi,
As per naming convention, I think it'd be nice if the methods were
named as:getmessage => get_message
getcode => get_codeIf those are corrected, +1 for this feature.
I was thinking of that - I would personally prefer get_message() and
get_code() naming, but that goes against pear's naming conventions, and
I want this to integrate well with pear (as a base class.)It's a PHP function, not PEAR code, so it should follow the PHP naming
style.
As I mentioned to Marcus, there are no naming conventions for OO code,
only procedural code (in PHP). Also, compliance with PEAR is a
pragmatic solution, because presumably all their code will be inheriting
from Exception. The largest, and the official OO library should be
in-sync with standard practices (and we have none yet regarding OO
code.)
-Sterling
Derick
--
"A business that makes nothing but money is a poor kind of business."
- Henry Ford
Hi,
As per naming convention, I think it'd be nice if the methods were
named as:getmessage => get_message
getcode => get_codeIf those are corrected, +1 for this feature.
I was thinking of that - I would personally prefer get_message() and
get_code() naming, but that goes against pear's naming conventions, and
I want this to integrate well with pear (as a base class.)It's a PHP function, not PEAR code, so it should follow the PHP naming
style.As I mentioned to Marcus, there are no naming conventions for OO code,
only procedural code (in PHP). Also, compliance with PEAR is a
pragmatic solution, because presumably all their code will be inheriting
from Exception. The largest, and the official OO library should be
in-sync with standard practices (and we have none yet regarding OO
code.)
Even if we don't have specific rules (yet) for OO stuff,
IMO, it should follow the existing rules.
--Jani