Skip to content

Instantly share code, notes, and snippets.

@KrzysztofMadejski
Created April 15, 2020 07:32
Show Gist options
  • Select an option

  • Save KrzysztofMadejski/9d4cd83f2def4636ad8a38e4258f482e to your computer and use it in GitHub Desktop.

Select an option

Save KrzysztofMadejski/9d4cd83f2def4636ad8a38e4258f482e to your computer and use it in GitHub Desktop.
Thinking about business errors implementation in go
type SchedulingError struct {
error
}
func (e *SchedulingError) Unwrap() error { return e.error }
// TODO NewSchedulingErrorf(string, ...args)
func NewSchedulingError(err error) SchedulingError {
return SchedulingError{error: err}
}
// return NewSchedulingError(ErrAlreadyScheduled)
// or even
// var ErrAlreadyScheduled = NewSchedulingError(errors.New("A scheduled run already exists for this parameters"))
// return NewRuntimeErrorf("Was not able to start transaction: %w", err) for non-business errors
// if we return struct (accepted as error interface) we are more verbose about what error do we return
// but do we get anything more apart naming this error?
// Not really.. and there is extra code generated written for unwrap etc.
// and still we can cast it to simple error
// Plus is: we can check if it's a business error with if errors.As(e, &schedulingError)
// to catch all package's bussines errors at once, but anyhow we should rather handle them one by one to account for all cases
// another option would be to have a code type SchedulingError struct { code int , string msg}
// var ErrAlreadyScheduled = NewSchedulingError(ERR_ALREADY_SCHEDULED, "A scheduled run already exists for this parameters")
// difference is with checking
// errors.Is(err, ErrAlreadyScheduled) vs err.Code == ERR_ALREADY_SCHEDULED
// would also have to define an Error method
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment