# Make exceptions great again

###### tags: `shaping-archive`

- Developers: -
- Appetite: half cycle

## Motivation

Currently, the usage of exceptions is not following best practices in gt4py:

- Exception classes are often (re-)defined per sub-module
- Exception classes are often associated with the source of the error and not the error that they represent
- Existing exception classes and error handling utilities are not available for re-use across the application

The lack of clear organization of error handling utilities leads to code duplication and lower quality utilities. The lack of meaningful exception classes makes it difficult both for users and us, developers, to handle and propagate errors correctly and extract the necessary information from messages to remedy the errors.

Since high quality error messages are an essential part of every compiler, this project aims to revamp the error handling in gt4py to follow best practices and promote consistency and code reuse.

## Overview

### Top-level module for error handling

Separate shared error handling objects and utilities into their own module. This way, all sub-modules (i.e. frontend, optimizer, codegen) have access to these utilities without introducing circular dependencies.

### Cover major use cases

- Signal compiler errors to users (e.g. symbol not found)
- Signal compiler warnings to users (e.g. symbol not used, operation has no effect)
- Signal internal errors

## Steps

1. Design and create an error handling module
2. Implement shared error handling code (e.g. formatting location + message + notes uniformly)
3. Examine exception usage and error classes across the application and:
- Design exception hierarchy for compiler errors
- Design exception hierarchy for internal errors as a supplement to Python's own exception hierarchy, if necessary
4. Rewrite existing code to use the new error handling module

## Non-goals

This project is strictly focused on isolating error handling facilities and providing clean exception class hierarchies for compiler errors and internal errors.

Out of the scope of this project:
- Implementing/using aggregate exceptions to bundle multiple compiler errors together
- Implementing compiler warnings
- Implementing any kind of logging

Furthermore, the task is not exhaustive in nature, it does not have to and probably should not change every `raise` across the codebase to use the new error handling facilities. It also does not have to provide every single exception class that's currently needed. The task is to lay the foundation for well-organized error handling that can be incorporated into existing and future code, and extended as needed.