Michal Wallace <[EMAIL PROTECTED]> wrote:
> What is the _return_cc attribute on an
> exception? Can I use it to resume the
> code as if the exception never happened?
When an exception is resumable, you can return by invoking this return
continuation. But details (i.e. is C<_return_cc> put into P1
automatically) will probably change. t/pmc/exception.t has some
examples.
> Do I have to fill it in manually? Or
> could it be automatic?
If the exception originated in the opcode-loop, it can be resumable -
but not all are changed yet. Have a look at C<real_exception()> in
*.ops. For these, setting the return continuation is done automatically.
> 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?
There will be some default information and user fields.
> So, if I throw a WarningException, could I
> just say "ignore it... go to the next line"?
You can always resume your own exceptions that you C<throw> yourself.
> 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?
I think, that we need classified ParrotExceptions. If HLLs POV differ
they can subclass these to their own needs.
> 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.
Yep.
> I know perl uses a return value instead of
> throwing an exception ("open or die", right?)..
Where die() is the exception.
> 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?
Very probably yes.
> Michal J Wallace
leo
