At 10:43 AM 8/10/00 -0400, Bennett Todd wrote:
>2000-08-09-21:00:31 Chaim Frenkel:
> > Making a module local to the using package, might have interesting
> > properties. [...]
> > The only breakage that I see, is having some way of globally setting
> > a variable. For example, turning on debugging for all uses. (FTP::Debug
> > I find quite popular.)
> >
> > Can anyone see any other breakage?
>
>Not other breakage, but another example of the same exact class
>of breakage. In RFC 70 I proposed some (hopefully minor) language
>cleanups to make it possible to have Fatal.pm actually work the
>way people want it. If it worked, then Fatal.pm would be getting
>some categories it supported, e.g. "use Fatal qw(:io);". I then
>suggested that the invoked categories could be posted into a
>testable variable, in case other module authors wished to cooperate
>with this protocol.
Why not, then, introduce non-fatal errors and a new keyword to throw them?
Something like quit(), which could take an error class, an error identifier
(a number or short string or something) and a message. It'd work like a
bare return, but also stick something in $@, and could be trappable. (Quit
with one parameter would default the class to generic, and the identifier
to unknown)
This way, when something needs to bail with a non-fatal error it could:
quit('io', 'READERROR', "Unable to read from file $foo");
and the code calling the sub could, if it wanted, could do a plain:
$foo = some_sub($file);
or:
{
use fatal;
eval {
$foo = some_sub($file);
};
if ($@) {
if ($@->nonfatal) {
# handle non-fatal errors
}
}
}
or something like that.
*) Define a set of c
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
