Hi Adam -

Adam Bregenzer wrote:

My biggest motivation for not having an exception class was to prevent
people from having a catch all with exceptions.  Personally, I think
that attitude is what has caused an over use of exceptions (making every
function throw Exception so as to not have to deal with them) as well as
let people use code without understanding exceptions (throwing a catch
all around an API call so they don't have to really handle any
exceptions).  I would like to be able to throw exceptions that must be
caught explicitly to help deter people from just ignoring them.  It
seems however that I am in the vast minority.

I agree with the basic premise the you want people to actually think about the Exceptions they are catching. In general I think apps should have their own exceptions and throw only Exceptions derived from those; in practice, I'm sure there will be lots of little apps that don't really need their own Exception tree and so it's nice to have a base Exception class. I don't agree, though, with the idea that if I don't know that your application throws YourException that it should by default leak through my error handling & come out as a PHP fatal error! Perhaps we're thinking of different scenarios for this stuff. I'm thinking of examples where I have a framework or system that may include 3rd party components to do work. For example, Phing (PHP5 Ant port) can use a number of PEAR packages or user-defined classes in its buildfiles. It would not be appropriate for any of those pieces of code to terminate the build by throwing an Exception that Phing doesn't expect (catch). At Phing task is an isolated activity and if a package that is used by a task throws any Throwable, it needs to be caught by the Phing task and logged so that the build script can continue (or abort, if the user has specified that behavior).

This isn't really an argument against using an interface, of course, but I definitely don't think it'd be good to build a system that was designed to get around catch() blocks. In development such a system might be helpful, but in production I think it would be a nightmare.

Hans

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to