This section describes the general process of implementing an exception handler in your application.
You should implement an exception handler in places where exceptions are likely to be generated. Common locations include:
When implementing an exception handler, begin by deciding which areas of your code are likely to generate system exceptions or are candidates for generating user exceptions.
List the classes and subclasses of the exceptions you expect to occur. These can be system exceptions or user exceptions. If you listed any user exceptions, add throw statements to your code to generate the exceptions for the appropriate circumstances.
Next, add the try...end try statement to your script to “surround” the code that can generate exceptions. Then add catch clauses to deal with the exception classes you listed. Within each catch clause, use functions from the Exception function library to retrieve information about the exception that occurred. Then add code to respond to the exception.
Typical responses to exceptions include:
In some cases, a problem can be resolved by re-executing sanScript statements. For example, if a record can’t be read and actively locked, you may want to re-execute your sanScript code until the record can be locked. Use the restart script statement to restart the current script. Use the restart try to re-execute the statements in the try...end try block.
In some cases, you may simply want to log or display information about the exception that occurred. Use the Exception_Message() function to retrieve the message text for the exception that was thrown.
In some cases, particularly when using object triggers, your exception handler may be thrown an exception that wasn’t intended for it. For example, assume within a try...end try block in your script, you call a Microsoft Dynamics GP procedure for which another product has a trigger registered. If the trigger processing procedure for the other product throws an exception that doesn’t get caught, the exception will be thrown back to your script, the script that caused the trigger to activate. Since your script wasn’t expecting the exception, it likely won’t be able handle it.
In this situation, use the Exception_Product() function to find out the ID of the product that threw the exception. If the exception came from another dictionary, and isn’t an exception you can handle, use the throw statement to rethrow the exception. Once rethrown, the exception can be handled by other exception handlers, if available. If no other exception handlers are available, an unhandled exception message will be displayed.
When an application is run using the runtime engine, any strings that overflow (exceed the 255 character limit) are automatically truncated. No message is displayed to the user and no exception will be thrown. For this reason, we recommend that you don’t use exception handling to handle string overflow situations.