Control Block
Description
The Try Recover block surrounds a block list with a safety net that catches exceptions. If an exception occurs in the "Try" block list the Try Recover block directs the program to the "Recovery" block list that can either manage the error or pass it along. This safety net can span nested called procedures. Try Recover simplifies error handling by separating concern for errors from the description of normal and expected program operation. For proper operation do not put an Exit block in either the "Try" or "Recover" sections.
Escapes
The Try Recover block does not produce any escapes.
Examples
An editor on the console is being used to enter a speed value. A Set Speed button next to the editor uses the editor speed value to set an axis speed:
If the editor does not have a valid number and the Set Speed Button is pressed an exception occurs with a particular Escape Code, number 27, that means there was a read problem.
The error message is titled "Unhandled EscapeCode". If there are no specific measures taken to catch the error a default description of the error is reported by Snap2Motion. However this message is not very meaningful to the person typing in the number. Putting the read operation inside a Try Recover block allows the error to be managed:
This produces this response instead:
A number of errors might occur inside a list of blocks. Different types of exceptions produce different Escape Code values. The Escape Code value can be read in the recover area of a Try Recover block with the expression "Escape Code" to discriminate the type of error.
Consider this similar example that sets acceleration. The entered value needs to be numeric or a Read Escape Code will be generated. The value needs to be greater than 0 or the Set Accel block will generate an Accel is 0 or Negative Escape Code.
If an invalid number is entered this message is displayed:
If the number is valid but negative this message is displayed:
Note that there is an additional case where if the Escape Code is not recognized a prompter is displayed saying so. If this was left out the default handler in the environment would have displayed the error.
Exceptions can "bubble up" through recovery blocks from a called procedure to the procedure that called it. This makes exception handling analogous to a management hierarchy in a company. Small problems are handled by the employees but if a big problem comes along management has to get involved. Consider the following example procedure named Perform_Move.
Perform_Move detects and handles the particular problem of a Motion Overrun. The axis was already in motion heading to a destination when it was told to go somewhere else. If the new destination is ahead of the current position and can be achieved without severely violating the deceleartion setting the new target is accepted and performed. If this can't be done then a Motion Overrun Escape Code occurs. In this case it is necessary to come to a stop and initiate a new move to the new destination. A motion overrun is a small problem that is handled in the recover block of Perform_Move. However there are other errors that Perform_Move does not have the ability to solve. If the problem is not a Motion Overrun Escape Code then the EscapeCode is re-issued in the else case. This is a concession that this Recover Block cannot solve the problem and that the calling routing needs to take responsibility. The calling routine looks like this:
In the "Try" section the destination parameter used by Perform_Move is filled in from an editor and Perform_Move is attempted. The "Recover" section attempts to distinguish between a number of problems. It checks if there was a Read exception with any of the information put into the editors. This exception would have come from its own "Try" block where the reading is being done. If that wasn't the problem it checks if there was a Position Limit Escape Code. This would occur if the entered destination value was numeric but beyond the positive or negative limits of motion. The block that detects this problem is the Begin Move To command inside Perform_Move. If that provided destination was outside of the positive and negative limits that block would generate the Position Limit Escape Code. The local recover block does not check for that error. Since it was not resolved locally the "else" case re-issued the exception and it was trapped in the recover block of Protected_Move where it was identified and addressed with an error message. The procedure Protected_Move is not necessarily the top-most procedure. It also conceeds that it might not be handling every possible problem and so re-issues the exception to its caller if it is not resolved. Generally a Try Recover block should re-issue any unhandled exceptions unless it is the very top-most procedure that must make a final determination regarding what to do with a problem.
Related Topics