Best practice concerning Exceptions
in [PEAR]
|
Prev: [ANNOUNCEMENT] HTML_Template_IT-1.3.0 (stable) Released.
Next: [ANNOUNCEMENT] pearweb_channelxml-1.15.1 (stable) Released.
From: Auke van Slooten on 10 Mar 2010 09:37 Hi, I've found the XML_RPC2 package (only after writing my own version of it ofcourse :( ..) and noticed that it declares quite a number of different exception classes. I've read the 'Error Handling Guidelines for PHP5 Packages' but couldn't find any information on when to use a new Exception class and when simply to use a new code and message. What is considered good practice for PHP5 exceptions? My own code uses just two exception classes, with about 8 different codes and messages. It seems the XML_RPC2 package throws a specific exception class for each error, skipping error codes. I understand that specific exception classes make it easier to catch just those types of error, but I'm not sure when to create a new exception class and when not to. Somehow the number of different exceptions defined in XML_RPC2 (15) seems excessive to me. regards, Auke van Slooten Muze
From: "Daniel O'Connor" on 10 Mar 2010 19:21 On Thu, Mar 11, 2010 at 1:07 AM, Auke van Slooten <auke(a)muze.nl> wrote: > Hi, > > I've found the XML_RPC2 package (only after writing my own version of it > ofcourse :( ..) and noticed that it declares quite a number of different > exception classes. I've read the 'Error Handling Guidelines for PHP5 > Packages' but couldn't find any information on when to use a new Exception > class and when simply to use a new code and message. > > What is considered good practice for PHP5 exceptions? My own code uses just > two exception classes, with about 8 different codes and messages. It seems > the XML_RPC2 package throws a specific exception class for each error, > skipping error codes. > > I find that most people (myself included) just rely on a general category of exception; and rarely if ever make use of exception codes. IE; I'd do: class Foo { public function bar($path) { // Checking to ensure things are 'valid' or 'expected' -> InvalidArgumentExceptions if (!file_exists($path)) { throw new InvalidArgumentException("Path must exist"); } // Doing the actual business logic; and unexpected things happen $content = file_get_contents($path); if (empty($content)) { throw new InvalidDataException("It looks like the supplied file is empty"); } } } rather than throw new FooException("Path must exist", Foo::INVALID_ARGUMENT); throw new FooException("It looks like the supplied file is empty", Foo::INVALID_DATA);
From: Michael Gauthier on 11 Mar 2010 09:13 On Thu, 2010-03-11 at 10:51 +1030, Daniel O'Connor wrote: > On Thu, Mar 11, 2010 at 1:07 AM, Auke van Slooten <auke(a)muze.nl> wrote: > > > Hi, > > > > I've found the XML_RPC2 package (only after writing my own version of it > > ofcourse :( ..) and noticed that it declares quite a number of different > > exception classes. I've read the 'Error Handling Guidelines for PHP5 > > Packages' but couldn't find any information on when to use a new Exception > > class and when simply to use a new code and message. > > > > What is considered good practice for PHP5 exceptions? My own code uses just > > two exception classes, with about 8 different codes and messages. It seems > > the XML_RPC2 package throws a specific exception class for each error, > > skipping error codes. > > > > > > I find that most people (myself included) just rely on a general category of > exception; and rarely if ever make use of exception codes. > > IE; I'd do: > > class Foo { > public function bar($path) { > // Checking to ensure things are 'valid' or 'expected' -> > InvalidArgumentExceptions > if (!file_exists($path)) { > throw new InvalidArgumentException("Path must exist"); > } > > // Doing the actual business logic; and unexpected things happen > $content = file_get_contents($path); > if (empty($content)) { > throw new InvalidDataException("It looks like the supplied file > is empty"); > } > } > } > > > rather than > > throw new FooException("Path must exist", Foo::INVALID_ARGUMENT); > throw new FooException("It looks like the supplied file is empty", > Foo::INVALID_DATA); Hi Auke, I typically create a new exception class for each category of error and then use codes to distinguish specific errors in those categories. I like to use and extend the built-in SPL exceptions where applicable. For example, in a web service API wrapper, I might have: * Foo_Exception * Foo_HttpException * Foo_AuthenticationException Then I might have more specific exceptions for specific circumstances. When deciding whether or not to create a new exception class, I think about how it would be to write error handling code for the error in question, and think about how the error should be logged. Hope this helps, Mike
From: Auke van Slooten on 11 Mar 2010 10:05 Michael Gauthier wrote: > On Thu, 2010-03-11 at 10:51 +1030, Daniel O'Connor wrote: >> On Thu, Mar 11, 2010 at 1:07 AM, Auke van Slooten <auke(a)muze.nl> wrote: >> >> I find that most people (myself included) just rely on a general category of >> exception; and rarely if ever make use of exception codes. >> [snip] > Hi Auke, > > I typically create a new exception class for each category of error and > then use codes to distinguish specific errors in those categories. I > like to use and extend the built-in SPL exceptions where applicable. > > For example, in a web service API wrapper, I might have: > > * Foo_Exception > * Foo_HttpException > * Foo_AuthenticationException > > Then I might have more specific exceptions for specific circumstances. > > When deciding whether or not to create a new exception class, I think > about how it would be to write error handling code for the error in > question, and think about how the error should be logged. Hi, thanks for answering. I've changed the API to incorporate more Exception classes. Still just four though, I couldn't think of any usefull case for more... I like the idea of using common SPL exceptions, but unless I'm mistaken you lose the ability to catch any library with one catch() statement? Currently all my exceptions inherit from the main exception class, so you can just 'catch( Ripcord_Exception $e )' and any exception the library throws will be caught. Using SPL exceptions, you would either also have to catch the SPL base exception or simply catch all exceptions. BTW, I've kept the unique error codes, since I think it's easier to use if you just want to have a single error handler and it adds no extra overhead. regards, Auke van Slooten Muze
From: Chuck Burgess on 11 Mar 2010 10:16
On Thu, Mar 11, 2010 at 9:05 AM, Auke van Slooten <auke(a)muze.nl> wrote: > Michael Gauthier wrote: > >> On Thu, 2010-03-11 at 10:51 +1030, Daniel O'Connor wrote: >> >>> On Thu, Mar 11, 2010 at 1:07 AM, Auke van Slooten <auke(a)muze.nl> wrote: >>> >>> I find that most people (myself included) just rely on a general category >>> of >>> exception; and rarely if ever make use of exception codes. >>> >>> [snip] > > Hi Auke, >> >> I typically create a new exception class for each category of error and >> then use codes to distinguish specific errors in those categories. I >> like to use and extend the built-in SPL exceptions where applicable. >> >> For example, in a web service API wrapper, I might have: >> >> * Foo_Exception >> * Foo_HttpException >> * Foo_AuthenticationException >> >> Then I might have more specific exceptions for specific circumstances. >> >> When deciding whether or not to create a new exception class, I think >> about how it would be to write error handling code for the error in >> question, and think about how the error should be logged. >> > > Hi, > > thanks for answering. I've changed the API to incorporate more Exception > classes. Still just four though, I couldn't think of any usefull case for > more... > > I like the idea of using common SPL exceptions, but unless I'm mistaken you > lose the ability to catch any library with one catch() statement? Currently > all my exceptions inherit from the main exception class, so you can just > 'catch( Ripcord_Exception $e )' and any exception the library throws will be > caught. Using SPL exceptions, you would either also have to catch the SPL > base exception or simply catch all exceptions. > > BTW, I've kept the unique error codes, since I think it's easier to use if > you just want to have a single error handler and it adds no extra overhead. > > > regards, > Auke van Slooten > Muze > Hi Auke, To help with your concern, have a look at how we're organizing exceptions in PEAR2 -- http://wiki.php.net/pear/rfc/pear2_exception_policy#full_code_example In short, you use a base exception *interface* rather than *class* for your package's "core" exception. Your concrete exception classes can then extend SPL exceptions while implementing your package's exception interface, thus making *both* characteristics catchable. Hope that helps... -- CRB |