/
README.in
89 lines (70 loc) · 3.31 KB
/
README.in
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
## seltzer
A specification for structured, user-facing error message values.
### Features
* Simple interfaces for exposing error information in a structured manner.
* Convenient builders for structured error values.
* Written in pure Java 17.
* [OSGi](https://www.osgi.org/) ready.
* [JPMS](https://en.wikipedia.org/wiki/Java_Platform_Module_System) ready.
* ISC license.
* High-coverage automated test suite.
### Motivation
Many applications and command-line tools need to produce error messages for
humans to read. Command-line tools will produce an error message as plain
text on the terminal, whilst graphical applications will probably produce
some sort of more complex error message dialog.
If a command-line application wants to include useful values along with the
error message such as the names of missing files, request IDs, and so on, the
only option it really has is to encode this information directly into the
error message. A GUI application, on the other hand, could display a basic
error message along with a graphical table of useful values. Library code wanting
to support both use-cases will typically bake some kind of structured error
type into the API. The `seltzer` package is an attempt to provide a set of
simple, structured API types so that [io7m](https://www.io7m.com/) packages
do not have to endlessly specify these kinds of structured error types over
and over.
Note: This is _not_ a machine-readable structured error logging API. For that,
use [OpenTelemetry](https://opentelemetry.io/).
### Building
```
$ mvn clean verify
```
### Usage
Application-specific structured error types can implement the
`SStructuredErrorType` interface. Application-specific exception types can
implement the `SStructuredErrorExceptionType` which contains some useful
default methods.
A structured error consists of the following:
|Item |Type | Description |
|-------------------|----------------------|-------------|
|Message |`String` | A basic error message, such as "File not found".|
|Attributes |`Map<String,String>` | A key/value map containing attributes such as `("File", "file.txt")`.|
|Remediating Action |`Optional<String>` | An optional, suggested remediating action such as "Specify a file that actually exists."|
|Error Code |`T` | An error code that uniquely identifies the _type_ of error, such as `error-file-not-found`|
|Exception |`Optional<Throwable>` | An optional exception. |
Structured error values are indexed by an error code type `T` to allow for
applications to strictly control error codes (and not have random error codes
proliferate through codebases).
The API contains an immutable `SStructuredError` type that applications can
use if they don't want to implement the interfaces themselves.
```
var error =
SStructuredError.builder("error-file-not-found", "File not found.")
.withAttribute("File", file.toString())
.withRemediatingAction("Use a file that exists.")
.withException(ex)
.build();
```
Applications catching exceptions can check if an `Exception` is a structured
error and display a more detailed error message if so:
```
try {
run();
} catch (Exception e) {
if (e instanceof SStructuredErrorType s) {
showDetailedError(s);
} else {
showBasicError(e);
}
}
```