Should always throw Error instead of JSON-RPC ErrorObject

[kael-shipman]

I know this is a bit of a code philosophy issue more than a strict right/wrong, so I submit it more as a suggestion with opinions about how it might be implemented.

Problem: I spent an hour last night trying to figure out where an error was coming from because my global error-handler was expecting a standard Error object and the code was throwing a simple JSON-RPC ErrorObject (i.e., no "message" and no stack trace).

Suggestion: Why don't we create an extension of Error that has a serialize method on it which returns the JSON-RPC representation of the error and throw that instead? That way standard error handling machinery would continue to work as expected using the standard message and stack trace of the Error object, while JSON-RPC machinery could easily translate that into an appropriate response.

I'd be happy to work on this if you're interested, or to hash over other solutions. Lemme know.

[kraenhansen]

I agree with @kael-shipman on this. I'd expect a parsed JsonRpcError to extend Error.