Openedge Development Error Handling
NOW Search the community Search Search Options Search Everything Search OpenEdge General Member Options Share this Page Details Created by ProductDocumentation When: 1 Oct 2013 3:03 Revisions: 1 Comments: 0 Related Tags abl code_share development_tools documentation dynamics management openedge openedge_10.0b openedge_10.1a openedge_10.1b openedge_10.1c openedge_10.2a openedge_codeshare progress_9.1e v9 Overview Forum Wiki Documents User Help Ideas Blog Subscribe 10.2A OpenEdge Development: Error Handling View this ManualClick the attachment below to view the PDF.Click here to view the HTML.What's InsideThis book provides a programming guide for ABL error handling.Intended AudienceThis book is intended for all ABL programmers. dverr.pdf Share
a block-making construct like the try statement. ABL blocks have something more than simple try blocks. Because ABL is a language with database semantics, all ABL blocks are undoable blocks that protect the database by undoing work when a block fails. This ability means you have more options for successfully resuming execution after an error. For example, you could retry a block after an error.All blocks have implicit error handling of some type, except for the simple DO block (a DO ... END block without transaction or error handling options). Explicit error handling for blocks https://community.progress.com/community_groups/openedge_general/w/openedgegeneral/1298.10-2a-openedge-development-error-handling is provided by an ON ERROR phrase and its many options. Default error handling is provided by an implicit ON ERROR phrase. Implicit and explicit ON ERROR phrases make up, in brief, traditional error handling.ABL adds built-in classes to represent errors as objects and a CATCH statement. These changes provide the basic mechanics of structured error handling in ABL. Here is a simple example:DO https://documentation.progress.com/output/ua/OpenEdge_latest/dverr/what-is-abl-structured-error-handling-3f.html ON ERROR UNDO, RETURN: FIND FIRST Customer WHERE CustNum = 1000. CATCH eSystemError AS Progress.Lang.SysError: MESSAGE "Not a valid customer number.".UNDO, THROW eSystemError.END CATCH.END. /* DO */The explicit ON ERROR phrase defines error handling for the block. In traditional error handling, the RETURN action occurs if any error is raised within the block. In structured error handling, the RETURN action occurs for any error that is not explicitly handled by a CATCH block. Since the FIND statement fails and raises a system error, the CATCH block executes and the MESSAGE statement displays a customer error message in the message area of the procedure window. However, the CATCH block concludes with the UNDO, THROW statement that directs the block enclosing the DO block to handle the eSystemError object. The enclosing block is the main procedure block, which by default uses traditional error handling. So, the default error message will also appear in a message block when the error object is thrown to the main procedure block. This demonstrates how error handling moves seamlessly between traditional and structured error handling.Copyright © 2015 Progress Software Corporation. All rights Reserved. Progress® OpenEdge® Release 11.6
computer languages, structured error handling is an error management model where an error is encapsulated by a class instance whose type depends on the type of error. Once created, this error object can be passed (thrown ) to various parts of a computer program, where it might be https://documentation.progress.com/output/ua/OpenEdge_latest/dvoop/structured-and-traditional-error-handling.html examined (caught ), modified, and optionally thrown to other parts of the program, all using the same standard mechanisms.ABL supports structured error handling using the following basic elements:Error classes — A set of built-in and user-defined classes that inherit directly or indirectly from the Progress.Lang.ProError class. These classes are used to instantiate error objects that encapsulate various types of system and application errors. When any system error occurs, the AVM instantiates and throws error handling an instance of the built-in class Progress.Lang.SysError (subclass of Progress.Lang.ProError). You can also instantiate and throw an application error object, a Progress.Lang.AppError (subclass of Progress.Lang.ProError) using a RETURN ERROR. You can extend Progress.Lang.AppError with additional members to define new classes that encapsulate different types of application errors. You can then throw error objects instantiated from these classes like all the built-in error classes.Error throwing mechanism — An UNDO, THROW option of several ABL elements openedge development error that raises ERROR and throws a specified error object to the associated block (the block where a particular ERROR condition is raised), which can handle the ERROR condition in a variety of well-defined ways. Using this option, you can throw a current system or application error object, or throw a new application error object that you create. Note that UNDO, THROW, by raising ERROR, also initiates the same UNDO handling as the traditional error handling model, when raising ERROR with a RETURN ERROR.Error catching mechanism — A CATCH statement that defines a special block that can catch and process an error object of any specified type that is thrown to the associated block. It is this CATCH block, which is available for use in all UNDO blocks, where you can decide whether to access the caught error object, throw the same or a new error object, or do nothing further with the error. Note that the CATCH statement is analogous to using the NO-ERROR option on a statement or the ON ERROR phrase (or default ON ERROR setting) on a block, both of which provide options for responding to ERROR conditions using traditional error handling. However, unlike the ON ERROR phrase, the CATCH block available with the CATCH statement is available for use in all UNDO blocks, including proc