12. Error Handling

ArkTS is designed to provide first-class support in responding to, and recovering from different erroneous conditions in a program.

Two kinds of situations can occur and interrupt normal program execution:

  • Runtime errors (e.g., null pointer dereferencing, array bounds checking, or division by zero);

  • Operation completion failures (e.g., the task of reading and processing data from a file on disk can fail if the file does not exist on a specified path, read permissions are not available, or else).

This specification uses the terms as follows:

  • “error” to denote runtime errors, and

  • “exception” to denote failures.

The difference between these two terms is that exceptions are the normal and expected way for an operation to complete. A program is expected to resolve some exceptions, and inform the user if it cannot.

On the contrary, errors indicate that there is a failure of the program logic, or even of the hardware. The program can recover in some but not all cases.

As a result, exceptions can be handled in a much more effective manner than errors.

Some modern programming languages support only exceptions; others support only errors. ArkTS is based on the presumption that both exceptions and errors must be supported. Exception and Error as predefined types are discussed below.

Exceptions are described in the chapter Experimental Features (see Exceptions) of this specification.


12.1. Errors

Error is the base class of all errors. Defining a new error class is normally not required because error classes for various cases (e.g., DivideByZeroError) are defined in the standard library (see Standard Library).

However, a developer can define a new error by using Error, or any derived class as the base of the new class. An example of the error handling is provided below:


 1 class DivideByZeroError extends Error {}
 2
 3 function divide(a: number, b: number): Number | null {
 4   try {
 5     return a / b
 6   }
 7   catch (x) {
 8     if (x instanceof DivideByZeroError)
 9       return null
10     return 0
11   }
12 }

A compile-time error occurs if a generic class is directly or indirectly a subclass of Error.

In most cases, errors are caused by the Virtual Machine, or by the standard libraries.

The throw statements (see throw Statements) allow throwing both exceptions and errors. Throwing exceptions provide a structured way to handle a range of unexpected situations in the application code. Throwing errors in such a context is not recommended.

The try statements (see try Statements) are used to handle errors in a manner similar to the handling of exceptions.

Note: Not every error can be recovered.

 1 class Exception extends Error {}
 2
 3 function handleAll(
 4   actions : () => void,
 5   error_handling_actions : () => void,
 6   exception_handling_actions : () => void)
 7 {
 8   try {
 9     actions()
10   }
11   catch (x) {
12     if (x instanceof Exception)
13       exception_handling_actions()
14     else if (x instanceof Error)
15       error_handling_actions()
16   }
17 }