Defining a THROWS clause

If you are using user-defined exceptions, you must define what exceptions might be thrown from a user-defined function or event. You use the Throws box in the Prototype window to do this.

When you need to add a THROWS clause

Any developers who call the function or event need to know what exceptions can be thrown from it so that their code can handle the exceptions. If a function contains a THROW statement that is not surrounded by a try-catch block that can deal with that type of exception, then the function must be declared to throw that type of an exception or some ancestor of that exception type.

There are two exception types that inherit from the Throwable object: Exception and RuntimeError. Typically, you add objects that inherit from Exception to the THROWS clause of a function. Exception objects are the parents of all checked exceptions, which are exceptions that must be dealt with when thrown and declared when throwing. You do not need to add runtime error objects to the THROWS clause, because they can occur at any time. You can catch these errors in a try-catch block, but you are not required to.

Adding a THROWS clause

You can add a THROWS clause to any PocketBuilder function or to any user event that is not defined by an event ID. To do so, drag and drop an exception object from the System Tree, or type the name of the object in the Throws box. If you type the names of multiple user objects in the Throws box, use a comma to separate the object names. When you drag and drop multiple user objects, PocketBuilder automatically adds the comma separators.

The PocketBuilder compiler checks whether a user-defined exception thrown on a function call in a script matches an exception in the THROWS clause for that function and prompts you if there is no matching exception in the THROWS clause.

You can create a user-defined exception object and inherit from it to define more specific lower-level exceptions. If you add a high-level exception to the THROWS clause, you can throw any lower-level exception in the script, but you risk hiding any useful information obtainable from the lower-level exception.

For more information about exception handling, see the Resource Guide.