4 ms·

func ThisCouldUseExceptions() error { err := Exceptions() if err != nil { return terrors.Propagate(err) } err =

• philosopher1234 5y ago
  func ThisCouldUseExceptions() error { err := Exceptions(arg) if err != nil { return fmt.Errorf("if a '%v' dev: %w", err) } err = GeneraliseBetter() if err != nil { return fmt.Errorf("has to actually: %w", err) } value, err = InFunctionsWithMultipleErrorPoints() if err != nil { return fmt.Errorf("read these errors: %w", err) } value, err := AlsoTheyHelp() if err != nil { return fmt.Errorf("they will actually be: %w", err) } chained_val, err := WithChaining(value) if err != nil { return fmt.Errorf("useful: %w", err) } err = AndPreventAccidentallyIgnoringErrors(chained_val) if err != nil { return fmt.Errorf("this isnt a real problem: %w", err) } }
• nmilo 5y ago
  Generally I find if you're writing code like that, your code is too high level. Okay, you've propagated errors, but what is the calling code going to do with those errors? I find large functions like that usually have enough context to handle the errors themselves. Errors, after all, are just conditions with a special name. It's not common to propagate conditions up several layers of code, so why do the same with errors?
  • the_duke 5y ago
    Go doesn't have (automatic) backtraces. If you don't wrap errors with a trace or with a custom message you often have no idea where the error came from.
    • merely-unlikely 5y ago
      if err != nil { return mherr.WrapErr(err, "optional context") } I just wrote a custom function that adds the stack trace to the error. I also have it setup as a code snippet in VS Code so all I have to do is type "if err" and hit tab. Yes it looks a bit verbose but it adds approximately zero extra work and makes error handling extremely easy by default. Also, turn on log flags to add line numbers. log.SetFlags(log.Llongfile | log.LstdFlags)