proposal: implement Error interface for error types

[rajatjindal]

building upon #127, can we add an Error method to error types so that in our sdk's we can directly return the error instead of having to map it to error msgs manually.

e.g. following method in the sdk could be just removed if we had that.

func errorVariantToError(err abc.Error) error {
	switch {
	case abc.ErrorInputNotSupported() == err:
		return fmt.Errorf("input not supported")
	case abc.RuntimeError() == err:
		return fmt.Errorf("runtime error")
	case abc.InvalidInput() == err:
		return fmt.Errorf("invalid input")
	default:
		return fmt.Errorf("no error provided by host implementation")
	}
}

Another thing we could possibly do is to replace "-" with " " automatically (to make it more readable), but its just a nice to have item.

[ydnar]

Seems reasonable. What's an error type?

Can you make a concrete proposal?

[rajatjindal]

I am referring to error type as variant in wit file. e.g.

  /// The set of errors which may be raised by functions in this interface
  variant error {
    /// Too many stores have been opened simultaneously. Closing one or more
    /// stores prior to retrying may address this.
    store-table-full,

    /// The host does not recognize the store label requested.
    no-such-store,

    /// The requesting component does not have access to the specified store
    /// (which may or may not exist).
    access-denied,

    /// Some implementation-specific error has occurred (e.g. I/O)
    other(string)
  }
}

but after typing the above I am thinking this would mean we also need the ability to differentiate error variant from any other variant somehow. do you know if that is possible today? can we somehow use the fact that if this is part of a result, that means it is an error.

[ydnar]

Can you identify a heuristic that works across a variety of WIT scenarios?