TRY-CATCH-FINALLY-ENDTRY

Handle exceptions

TRY
  .
  .     ; TRY block
  .
[CATCH (exception_var[, @exception_type])
  .
  .     ; one or more CATCH blocks
  .]
[FINALLY
  .
  .     ; FINALLY block
  .]
ENDTRY

Arguments

exception_var

A CATCH block exception variable, whose scope is confined to the CATCH block in which it is declared.

exception_type

The type of the exception. The default type is System.Exception.

Discussion

The TRY block should contain all of the statements that are subject to the exception handler. It can have zero or more CATCH statements, each handling a different type of exception. A CATCH block is only entered when an appropriate exception is being caught.

When a thrown exception is being processed, the system looks through the CATCH blocks for an exception type that is equal to or in the hierarchy of the thrown exception. The first CATCH statement that meets the condition is executed. If no CATCH blocks in the current frame handle this type of thrown exception, the stack continues to unwind either until an appropriate CATCH block is found is found or until an unhandled exception is reported.

Exception_var must be type System.Exception, or it must inherit from it. It cannot be a statement keyword or a keyword reserved for the procedure division. You don’t need to declare a CATCH block exception_var in the data section. If a CATCH block catches a thrown exception, the exception_var for the block will be assigned the instance of the thrown exception that it caught.

If a CATCH block does not rethrow the caught exception, the destructor for the exception is run automatically when the CATCH block is exited.

A call to a label in a higher scope is not allowed in a TRY-CATCH-FINALLY statement. You should never throw an exception in a callback to be caught outside the callback.

You can throw an exception using the THROW statement.

You can place any code that must be run regardless of whether or not an exception is handled in the FINALLY block. Typically the FINALLY block releases critical resources, such as file locks. At least one CATCH or one FINALLY block is required. If a FINALLY block exists, it is always run on exit from the TRY or CATCH block. Exit conditions include end of block, RETURN statements, and statements that jump to a label outside the TRY/CATCH block.

The following statements and routine calls are not allowed in a FINALLY block: XRETURN, FRETURN, MRETURN, CALL, RETURN, EXITTRY, EXITE, and DBL$EXITERROR. Code jumps (for example, GOTO, I/O error list, EXITLOOP, READS(,,eof), and so on) are also not permitted. An EXIT statement is allowed if the referenced BEGIN-END block resides entirely within the FINALLY block. In Synergy .NET, CALL-RETURN is not allowed inside a TRY block.

We highly recommend that you use I/O error lists instead of ONERROR or TRY-CATCH in Synergy .NET.

See also

Structured exception handling
THROW statement

Examples

subroutine TestExceptions
record
    tt          ,i4
    fl          ,i4
proc
    try
    begin
       open(tt=0,i,"tt:")
      ;open(fl=0,i,"dontfindme.txt")            ;Uncomment this line to see
                                                ; IO exception being caught
      throw new Exception("My Error Message")   ;Throws the exception here
      writes(tt,"SHOULD NOT SEE THIS!")
    end
    catch (ioe, @SynIOException)                ;Catch Synergy IO exception
      begin
      writes(tt,"Caught this IO error:"+ioe.Message)
      end
    catch (e, @Exception)                       ;Catch any exception not handled
                                                ; by a previous catch 
      begin
        writes(tt,"Caught this error:"+e.Message)  
      end
    finally
      begin
        writes(tt,"Now in finally block")
        close(tt)           ;Use FINALLY block to release critical resources
      end
    endtry
endsubroutine