On Wed, 3 Dec 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 12:17 PM +0100 12/3/03, Leopold Toetsch wrote:
>
> >>Create an Exception class hierarchy?
>
> > I'm not 100% sure I want to go with a real OO style of exceptions,
> > but that might just be the neo-luddite in me.
>
> It probably depends what HLL want to have. Anyway, I was thinking of
> pre-constructing a bunch of constant exception objects for internal
> usage.
I'm trying to understand the question here:
What is the _return_cc attribute on an
exception? Can I use it to resume the
code as if the exception never happened?
Do I have to fill it in manually? Or
could it be automatic?
I'm picturing exceptions as continuations
with an arbitrary message attached... Right
now that message is a string, but eventually
it could be any PMC... Is that about right?
So, if I throw a WarningException, could I
just say "ignore it... go to the next line"?
As for the message, I'm trying to think of
a good reason to standardize that attached
PMC. For example, if I try to open a file
in python and it fails, I get an exception
of class IOError... But if I call a perl
routine that throws the perl equivalent...
What should happen? Should I just catch
PerlException instead?
Each HLL is going to want its own class
hierarchy for exceptions... But it might
be nice to have a predefined hierarchy that
parrot uses internally.
I know perl uses a return value instead of
throwing an exception ("open or die", right?)..
So would parrot's internal file-opener just
throw a ParrotFileException? So perl's
open() command catches it and returns 0,
while python's open() command catches it
and throws a new IOError?
Am I on the right track?
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: [EMAIL PROTECTED]
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------
