Skip to content
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Commit c49bd4b

Browse files
committedJan 29, 2025·
ADR: Custom Exceptions Patterns
Signed-off-by: Anastas Stoyanovsky <astoyano@redhat.com>
1 parent e12aeea commit c49bd4b

File tree

2 files changed

+25
-0
lines changed

2 files changed

+25
-0
lines changed
 

‎.spellcheck-en-custom.txt

+2
Original file line numberDiff line numberDiff line change
@@ -45,6 +45,7 @@ DCO
4545
Dependabot
4646
dev
4747
disambiguating
48+
discoverability
4849
ditaa
4950
Docling
5051
docling
@@ -227,6 +228,7 @@ specifiying
227228
splitter
228229
src
229230
Srivastava
231+
SSL
230232
Staar
231233
Standup
232234
subcommand

‎docs/adr-custom-exceptions.md

+23
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
# InstructLab Custom Exceptions Pattern
2+
3+
## Context
4+
5+
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.
6+
7+
These issues will compound whenever REST APIs begin development.
8+
9+
## Decision
10+
11+
InstructLab will adopt custom exceptions to handle specific faults which are then caught in the user-facing layer (CLI, REST API, &c).
12+
13+
## Status
14+
15+
Accepted
16+
17+
## Consequences
18+
19+
* Verification of exhaustive error handling will be clear within a code section that can raise.
20+
* CLI layer error handling will be easy to understand and trace.
21+
* Whenever REST APIs are developed, HTTP error codes should be easier to be associated with specific exceptions.
22+
* It should be easier to compose useful error messages for the user.
23+
* It should be easier to correctly scope exception handling (consider a `URLError` raised about SSL verification, for example, versus a custom `SSlVerificationException`).

0 commit comments

Comments
 (0)
Please sign in to comment.