Skip to content

ADR: Custom Exceptions Patterns #186

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

ADR: Custom Exceptions Patterns #186

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions .spellcheck-en-custom.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,6 +45,7 @@ DCO
Dependabot
dev
disambiguating
discoverability
ditaa
Docling
docling
Expand Down Expand Up @@ -227,6 +228,7 @@ specifiying
splitter
src
Srivastava
SSL
Staar
Standup
subcommand
Expand Down
23 changes: 23 additions & 0 deletions docs/adr-custom-exceptions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# InstructLab Custom Exceptions Pattern

## Context

The historically pervasive pattern for exception handling during application runtime is to catch internally raised exceptions in the CLI layer and use `click.secho` followed by `click.exceptions.Exit` to display a useful error message to the user before exiting the application. This leaves a risk of intermediate calls between the site of the exception and the user-facing layer changing, leading to missed new exceptions and outdated caught exceptions. A second issue is that of discoverability and verification: given a `click.exceptions.Exit` exception handling, it is not clear from the code where the caught exception originates from in the call stack, and, similarly, given a piece of code that can raise an exception, it is not clear from the local code whether that exception is properly handled in the CLI layer without investigation.

These issues will compound whenever REST APIs begin development.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and/or whenever the SDK APIs begin development.


## Decision

InstructLab will adopt custom exceptions to handle specific faults which are then caught in the user-facing layer (CLI, REST API, &c).

## Status

Accepted

## Consequences

* Verification of exhaustive error handling will be clear within a code section that can raise.
* CLI layer error handling will be easy to understand and trace.
* Whenever REST APIs are developed, HTTP error codes should be easier to be associated with specific exceptions.
* It should be easier to compose useful error messages for the user.
* It should be easier to correctly scope exception handling (consider a `URLError` raised about SSL verification, for example, versus a custom `SSlVerificationException`).
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm with you in general but not for this specific example (as I expressed in the patch), for the reason that we cannot and should not enumerate all the possible ways a request may fail, so letting URLError bubble up is fine here. (Caught further up the call stack and transformed into ilab specific exception as needed.)