Expose original error object in promises (or callbacks)

[mhart]

The current error structure in the promises implementation only supports a very simple message, so for situations where an error is thrown from the node.js stack for example, the error is converted into a string and all stack information etc is lost:

aws-sdk-js/lib/http.js

Line 304 in 99f6bfd

callbacks.onError({ code: 'NetworkingError', message: e.toString() });

It would be nice if the original error object could be added to the error structure so that it can be inspected, etc.

Edit: if node.js-style callbacks are going to be used (fingers crossed), then there shouldn't be any need for this error structure at all - just use/expose JS errors/exceptions.

[lsegal]

Thanks. Clobbering the stack trace is a bug, IMO.

[trevorrowe]

Fixed in 146b643 and released with 0.9.1-pre.2.

[mhart]

I think this may have been closed a bit summarily. The code is still littered with usages of this custom {code: '', message: ''} structure and strings instead of real JavaScript exceptions (which makes it very hard to deal with errors when they arise - are they JavaScript Error objects, are they some custom object, are they strings, etc).

Perhaps you want to extend the JS Error object and create your own AwsError or similar: http://www.devthought.com/2011/12/22/a-string-is-not-an-error/

Some examples:

aws-sdk-js/lib/xml/parser_xml2js.js

Line 56 in 92c766f

throw { code: 'AWS.XML.Parser.Error', message: error.message };

aws-sdk-js/lib/xml/parser_xml2js.js

Line 134 in 92c766f

throw { code: 'AWS.XML.Parser.Error', message: msg };

aws-sdk-js/lib/xml/parser_xml2js.js

Line 166 in 92c766f

throw 'unhandled timestamp format: ' + value;

aws-sdk-js/lib/query_client.js

Line 67 in 4fa2d20

return {

aws-sdk-js/lib/rest_xml_client.js

Line 107 in 4fa2d20

return {

aws-sdk-js/lib/services/ec2.js

Line 54 in 8d32fd9

return {

aws-sdk-js/lib/services/s3.js

Line 181 in 8d32fd9

return {

[trevorrowe]

There is a strong pattern across AWS services where the services may respond to a request with an error "code" and "message". The code is always a short string and the message is a longer description, often with details. When I call the EC2 DescribeInstances operation I might get an error back (in XML) that has the following attributes:

• code: InvalidInstanceID.NotFound
• message: "The instance ID 'i-12345678' does not exist"

The original intent was to limit the number of attributes a user needed to check on errors returned by the SDK. If errors generated by the SDK (or its dependency) mimicked those returned by the services then error handling could be generalized to a point.

That said, I see the issue where these object do not generate stack traces and can actually make error handling more difficult. At this point, I think standardizing on An error class (like AWS.Error) that extends Error makes good sense.

[lsegal]

I'm prototyping something based on AWS.Error right now, FYI.

[lsegal]

See the node-errors branch for the code.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.