[rpercy]

Not really. In a language like Java, some of the questions I'd have to ask myself are:

  - Should I try to catch the exception, or just let it 
    bubble up and edit my interface to include it?
  - Should I create a new exception type or reuse an existing one?
  - Should I throw a checked or unchecked exception?
  - Am I exposing implementation details via my interface? 
    (eg I don't want to throw an SQLException from GenericDataSourceWidget.connect())

In golang, I know there's really just the one pattern: check if err != nil, prepend a descriptive message, and return it.

[Groxx]

>check if err != nil, prepend a descriptive message, and return it.

That'd be the RuntimeException equivalent, sure. But what do you do for the equivalent of checked exceptions? Errors are frequently recoverable, "err != nil" alone does nothing to help you there, and string manipulation is a horrific alternative to types.

[cdelsolar]

You can have typed errors too. This is fairly common in Go. As long as it implements the Error interface.