Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > That's not what's proposed. The core and other users would
> > use classes derived from Error to raise errors. Other users
> > could even just Error itself. Exception is reserved for
> > exceptions that don't and shouldn't derive from Error.
>
> I'm still having a hard time with this. Maybe everyone else
> sees it and can explain it to me. All I see is, you have a
> mechanism for implementing non-local flow control. The reason
> the control flow skipped is surely opaque and irrelevant to
> the mechanism? What the program decides to do with that
> exception, likewise. Success and failure are more or less
> arbitrary interpretations we place on these exceptions.
I've taken out the concept of a built-in Error class.
It turns out that I really just don't want to have to write
throw Exception::Error::App::DB tag => "ABC.1234",
message => "Can't write to table $table.";
instead of
throw Error_DB "ABC.1234: Can't write to table $table.";
RFC 88 (now, but not until recently) lets me do that via
inheritance, so I now gladly turn all the other built-in
error stuff over to RFC 80 ;-)
> > No. I want Error to be able to be extended, over the
> > evolution of Perl 6, to include anything that is deemed
> > suitable for error handling. I don't want any of that to
> > interfer with base Exception functionality.
Ok, so now I may have to go and turn off something new in a
light-weight class. I can live with that, as long as RFC 80
keeps this in mind.
Yours, &c, Tony Olekshy
