kristjanmik/apis — pull request #40 by arnorhs (2013-05-04 03:54:04+00:00)
Title: Adding more info to the default error handler - should fix #35

I basically added some more info into the restify uncaughtexception handler.

So if endpoint developers do this on errors that they don't want to support (that is, most normal error cases), we should get some nice info in the console:

example:

if (error) {
throw new Error(error);
}

no need to muck with our own error handlers (unless there is specific state within the request that you'd want to expose)

This approach maintains the originating stack trace, so we'll have a clearer idea about what happened.

So basically as a rule: always throw the error. If the error originated from a callback and you are handling it yourself, then pass that into the error handler..

For cases where developers want to just generate an error, eg. "this function should never return the number 42" - then you do:

if (number == 42) {
throw new Error("Number should never ever be 42!");
}

And I think we should be in business.

tldr: if you have an error object, throw a new error with that error in the constructor. if you don't pass in a string.