@maybebtc its ok if the error doesnt show the name. being able to compare is the important part. (go solved this incorrectly IMO. errors with params should be comparable statically. this doesnt currently leverage the type system well.

experimenting....

type ErrNotFound struct {
  key string
}

func (e *ErrNotFound) Error() string {
  return fmt.Sprintf("merkledag: %s not found", e.key)
}

// elsewhere
foo, err := doSomething()
if err != nil {
  if _, ok err.(mdag.ErrNotFound); ok {
    // this is a not found error.
  }
}

@whyrusleeping @maybebtc thoughts on this pattern \o ? it's annoyingly verbose, but it gives us ability to make errors with params that we can still compare. idk i havent thought about it more than 2 min. this may not be needed at all.

@jbenet If, in the future, we feel pain and need the information in the error, this is a viable solution. The verbosity may only be worth it if we're feeling real pain.

For now, we have enough information to get errors back out the the user. #alphafocus

aside, can also do:

switch err := err.(type) {
case ParseError:
  PrintParseError(err)
}

@maybebtc i usually use https://github.com/jbenet/go-ipfs/pull/224/files to CR and see exactly what's changed.

Ive been toying with the idea of a wrapped error interface:

type WrappedError interface {
    Error() string
    Root() error
}

func WrapError(err error, context interface{}) error {
    ...
}

This way we could have more information about where each error origination, and still be able to compared the root error types.

I like this. there really should be a more sophisticated Error interface, like context.Context. shrug not a big deal atm.

Ill keep it around, maybe after the alpha I can work on refitting our error handling system