JVM | Platform | Status |
---|---|---|
OpenJDK (Temurin) Current | Linux | |
OpenJDK (Temurin) LTS | Linux | |
OpenJDK (Temurin) Current | Windows | |
OpenJDK (Temurin) LTS | Windows |
A specification for structured, user-facing error message values.
- Simple interfaces for exposing error information in a structured manner.
- Convenient builders for structured error values.
- Written in pure Java 17.
- OSGi ready.
- JPMS ready.
- ISC license.
- High-coverage automated test suite.
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 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.
$ mvn clean verify
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);
}
}