Skip to content
This repository has been archived by the owner on Sep 25, 2023. It is now read-only.
/ must Public archive

Go library to shorten handling of impossible conditions

License

Notifications You must be signed in to change notification settings

ridge/must

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

21 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Go library to shorten handling of impossible conditions

Go Reference

This repository is archived. See https://github.com/dottedmag/must for the current version.

must.OK(os.Unsetenv("FOO"))
bs := must.OK1(json.Marshal(dataStructureDefinedInCode))
defer must.Do(f.Close)

is

if err := os.Unsetenv("FOO"); err != nil {
     panic(err)
}
bs, err := json.Marshal(dataStructureDefinedInCode)
if err != nil {
    panic(err)
}
defer func() {
    if err := f.Close(); err != nil {
        panic(err)
    }
}()

Why panic?

Go error handling style is practical for majority of errors. However not all errors are meaningful and actionable by the caller, so it does not make sense to surface them.

Go tacitly acknowledges it by providing functions regex.MustCompile and template.Must in the standard library. This library expands on the same idea.

Where is it useful?

The library is proven to be useful in the following situations:

  • Programming errors in all kinds of code, similar to regex.MustCompile,
  • Filesystem-related errors in a build system,
  • Fatal errors in server-side SaaS code.

The last point needs an explanation.

Unlike CLI tools where errors ought to be handled in a way meaningful to a user who might not know the internals of the application, server-side SaaS applications are run by the SREs or developers who do not need the extra wrapping, and instead require fatal errors to be delivered reliably and with all gory details.

Passing errors up the stack in a regular Go way risks losing the error (by forgetting to wrap it, or by swallowing it completely), and prevents the original stacktrace from being surfaced. panicing at the place of fatal error is reliable and precise.

Is it a good idea to use must everywhere?

Definitely not. Go rules for error handling are well thought-out. Reserve must for programming errors and impossible conditions.

Legal

Copyright Tectonic Labs Ltd.

Licensed under Apache 2.0 license.

Authors: