An open API service providing package, version and dependency metadata of many open source software ecosystems and registries.

Top 8.2% on proxy.golang.org

proxy.golang.org : github.com/polydawn/go-errcat

errcat is a simple universal error type that helps you produce errors that are both easy to categorize and handle, and also easy to maintain the original messages of. errcat does this by separating the two major parts of an error: the category and the message. The category is a value which you can switch on. *It is expected that the category field may be reassigned* as the error propagates up the stack. The message is the human-readable description of the error that occured. It *may* be further prepended with additional context info as it propagates out... or, not. The message may be redundant with the category: it is expected that the message will be printed to a user, while the category will not necessarily reach the user (it may be consumed by another layer of code, which may choose to re-categorize the error on its way up). Additional "details" may be attached in the Error.Details field; sometimes this can be used to provide key-value pairs which are useful in logging for other remote systems which must handle errors. However, usage of this should be minimized unless good reason is known; all handling logic should branch primarily on the category field, because that's what it's there for. errcat is specifically designed to be *serializable*, and just as importantly, *unserializable* again. This is helpful for making API-driven applications with consistent and reliably round-trip-able errors. errcat errors in json should appear as a very simple object: If details are present, they're an additional map[string]string: Typical usage patterns involve a const block in each package which enumerates the set of error category values that this package may return. When calling functions using the errcat convention, the callers may switch upon the returned Error's Category property: Use the public functions of this package to create errors, and accessor functions (like 'errcat.Category' for example) to access the properties. All your code should use the stdlib `error` interface and these package functions. Using the interfaces rather than a concrete type means you (or others) can easily vendor this library even under different import paths, and all of your error types will interact correctly. Prefering the `error` type to the `errcat.Error` interface avoids common developer irritants that may otherwise arrise from type specificity when putting both types into a variable named "err"; all of the errcat package funcs both take and return `error` interfaces for this reason. Functions internal to packages may chose to panic up their errors. It is idiomatic to recover such internal panics and return the error as normal at the top of the package even when using panics as a non-local return system internally.

Registry - Source - Documentation - JSON
purl: pkg:golang/github.com/polydawn/go-errcat
License: Apache-2.0
Latest release: over 6 years ago
First release: over 6 years ago
Namespace: github.com/polydawn
Last synced: 2 months ago

    Loading...
    Readme
    Loading...