Parrot Virtual Machine/Exception Subsystem
Exception handling has become a staple in most modern programming languages. Parrot, since it intends to host many such languages must support a robust exception system. Not only does Parrot use exceptions for error handling and recovery, but it also encourages the use of control flow exceptions to implement high-level control flow features of those languages as well. What this means is that the exception subsystem is one of the most important for language implementers to become familiar with.
Parrot's exception system is currently being reimplemented to make it more powerful, scalable, internally consistent and robust. Some of the information in this page may be out of date.
Exceptions: The Basics Edit
Exceptions are broken down into two primary parts: the exception object and the exception handler. Exception handlers are like subroutines in many ways, and must be specially registered with Parrot before they can be used. When Parrot detects an error, it creates an exception object by including information about the error, a continuation for the current control flow state, and a few other pieces of information. Exceptions, like most everything else in Parrot, are PMCs and can be stored, manipulated, and used like other PMCs.
Once the exception object is created, Parrot looks through its list of handlers, and passes its exception object to each. Handlers are stored in a stack-like structure, and the most recently registered handler will have the first access to the exception object. The handler can do one of several things. First, it can handle the exception: It can fix the error, call the return continuation that is within the exception object, and returns control flow back to where it was before the error occurred. Second, it could re-throw the exception, passing it to the next handler in the stack. Third, it could ignore the exception. Exceptions which are ignored, or for which no handlers are available, cause Parrot to exit.