Error Handling Guide

TVM contains structured error classes to indicate specific types of error. Please raise a specific error type when possible, so that users can write code to handle a specific error category if necessary. You can directly raise the specific error object in python. In other languages like c++, you simply add <ErrorType>: prefix to the error message(see below).

Note

Please refer to tvm.error for the list of errors.

Raise a Specific Error in C++

You can add <ErrorType>: prefix to your error message to raise an error of the corresponding type. Note that you do not have to add a new type tvm.error.TVMError will be raised by default when there is no error type prefix in the message. This mechanism works for both LOG(FATAL) and TVM_FFI_ICHECK macros. The following code gives an example on how to do so.

// src/api_test.cc
void ErrorTest(int x, int y) {
  TVM_FFI_ICHECK_EQ(x, y) << "ValueError: expect x and y to be equal."
  if (x == 1) {
    LOG(FATAL) << "InternalError: cannot reach here";
  }
}

When a C++ function registered via the FFI raises an error with a typed prefix, the TVM FFI system will automatically map it to the corresponding Python exception class. For example, a ValueError: prefix in the error message will raise a Python ValueError, and an InternalError: prefix will raise tvm.error.InternalError.

TVM’s FFI system combines both the Python and C++ stacktraces into a single message, and generates the corresponding error class automatically.

How to choose an Error Type 

You can go through the error types are listed below, try to use common sense and also refer to the choices in the existing code. We try to keep a reasonable amount of error types. If you feel there is a need to add a new error type, do the following steps:

Send a RFC proposal with a description and usage examples in the current codebase.
Add the new error type to tvm.error with clear documents.
Update the list in this file to include the new error type.
Change the code to use the new error type.

We also recommend to use less abstraction when creating the short error messages. The code is more readable in this way, and also opens path to craft specific error messages when necessary.

def preferred():
    # Very clear about what is being raised and what is the error message.
    raise OpNotImplemented("Operator relu is not implemented in the ONNX frontend")

def _op_not_implemented(op_name):
    return OpNotImplemented("Operator {} is not implemented.").format(op_name)

def not_preferred():
    # Introduces another level of indirection.
    raise _op_not_implemented("relu")

If we need to introduce a wrapper function that constructs multi-line error messages, please put wrapper in the same file so other developers can look up the implementation easily.

Error Handling Guide

Raise a Specific Error in C++

How to choose an Error Type

How to choose an Error Type 