On Sat, 28 Aug 2004 12:16:42 +0800, Alan Knowles <alan@xxxxxxxxxxxx> wrote:
>
> >
> > This is certainly a possibility, but the instant you have a method
> > that bubbles up exceptions from more than one package that it uses,
> > you have the same mess that you have with PEAR_Error. Which error
> > belongs to which package? The error message, or perhaps the trace is
> > the only way to locate it. That results in some seriously crappy
> > kludges. For instance, in the PEAR installer, the error message is
> > regexed to determine whether an error is from a particular area.
> > Suddenly, you have BC issues with the error messages.
> >
> > A solution might be to prohibit bubbling up of any PEAR_Exceptions
> > from other packages, as in "you may only throw, and never bubble up a
> > PEAR_Exception"
> >
> > What do you think?
>
>
> Yes sounds good.- The idea being that if you need to bubble it up, you
> can ask the original maintainer to implement custom classes.. - but not
> enforce by abstract (especially as PEAR_Exception may be used by
> non-pear classes, as a quick placeholder, when prototyping a project)
>
I would recommend rather that we make it a rule that you *may* use
PEAR_Exception when prototyping, but any release must have its own
exceptions class. Honestly, how hard is it to:
class My_Package_Exception extends PEAR_Exception {}
?
I can see if the package name may change it might be an annoyance, but
you can fix this with a *very* simple search and replace. The package
name would only change before a package is accepted, though, and a
package exception would be very easy to add before a first release. We
could also allow devel and alpha packages to use PEAR_Exception if we
wish.
--
DB_DataObject_FormBuilder - The database at your fingertips
http://pear.php.net/package/DB_DataObject_FormBuilder
paperCrane --Justin Patrin--
--
PEAR Core List Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
|
