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