All geek questions in one place

What is the best way to detect and link errors in Node.js?

I am writing a module that speaks with the REST API, and since the REST API provides nice, semantic error answers (e.g. 403 vs 503), I want to pass these semantic errors to callers.

(Edit: what I mean by this, the caller must be able to programmatically understand the cause of the error and act accordingly, for example, display the corresponding user interface.)

What is the best way for me to do?

  • Create my own subclasses of Error for these semantics, for example. mymodule.ForbiddenError , mymodule.ServiceUnavailableError ? Then callers check instanceof for semantics. This is most typical for statically typed languages ​​such as C # and Java.

  • Add for example. a mymoduleCode for standard Error instances with semantic strings like 'Forbidden' or 'ServiceUnavailable' . Node.js itself does this, for example. code: 'ECONNREFUSED' .

  • Another way?

==

Now I am writing another module that wraps the first module. I do not want to reveal the internal errors of the module directly, but it would be nice to compose / wrap them for debugging.

What again is the best way for me to do?

However, most of the tools I've seen display only the stack property of Error instances, so this data will be lost in these cases. Is there a regular / regular way that already exists?

+6
source share
5 answers

Found this wonderful article that talks about this:

http://www.joyent.com/developers/node/design/errors

Too many to insert here, but under Specific Recommendations, paragraphs 2 through 5 address this:

  • It’s clear what your function does.
  • Use Error objects (or subclasses) for all errors and implement the Error contract.
  • Use the Error name property to distinguish errors programmatically.
  • Enlarge the Error object with properties that explain the details.
  • If you pass a low-level error to your caller, consider it instead.

And, in particular, the article refers to this module for wrapping / linking errors:

https://github.com/davepacheco/node-verror

I'm not sure that I will follow these exact conventions - for example, I see the value of having the code property in the application domain, but the principles are very useful.

+4
source

The use case that you describe is one that Node is definitely underestimating right now. Since there are conventions that are used, they are usually a mixture of:

  • Creating new types of errors that are simply inferred from the Error constructor. Useful mainly for creating high-level error categories. You can use instanceof to distinguish between types of errors, but this is not very similar to JavaScripty.
  • Creating subtypes of Java-style errors that take another error as a constructor argument and then complete them. If you are creating an API subtype, you mainly use polymorphism instead of sending directly to handle type-based errors.
  • Creating semantically useful error messages through the error constructor. This is the pattern that I often use.
  • Attaching properties to errors, which is also extremely common.
  • Create an unbound error handling API that can be called from any cause of the error. This gives you one place to concentrate all the code that determines what your error is and what you should do with it, and enter any dependencies necessary to handle the errors.

The real problem here is that these are all special mechanisms, and I would not say that any of them has reached critical mass. I think this is partly due to the fact that the combination of asynchrony and JavaScript makes it difficult to correctly and completely fix errors, so the recommendation is usually to close the whole process after receiving the error information.

This does not handle expected errors very well, but I think that most of these errors are either captured by the framework (for example, Express error handlers) or placed in a Node callback convention. In short, I think there is a place to define some conventions, because contemporary art is not so tricky.

+6
source

Change I am new to StackOverflow and Node.js. Someone should answer this question! :-)

If you are leaving from Java / C #, come to JavaScript! I have never seen the Node.js library use instanceof to check for error types, but, as you said, it is quite common in static languages.

With this in mind, it is typically simple to create new errors and callback using NodeJS (err, response) callback methods.

I run into error messages from other modules all the time, and it’s useful to know where they came from, or to create wrapped error messages that can hide where they actually died from me (it takes more on my part to dig around).

An example of creating a function that could handle rest error messages that are strings (or in your case invalid):

 function myFunction(callback) { callRestAPI('http://someApi.com/request', function(errorString, jsonResponse) { if (errorString) { callback(new Error("something wrong in myFunction! " + errorString)); } else { callback(null, JSON.parse(jsonResponse)); } }); }

In your case, checking for "errorString" will be basically the answer (403/503), and you can structure the error message to send to new Error( ... ) , for example. new Error('Failed! Got response 403!')

Maybe I missed your point, maybe someone else might be more thorough.

After reading it again, you can post which module you are wrapping. Is this node-request?

+1
source

I'm also pretty new to node, so grab this with salt, but I'll go with your option # 2 by adding a property. (It is also offered here) .

This is pretty much your original # 2 option. If the error handlers just register the stack and not the error itself, this is their error. :-) (seriously, not sure how you can do better)

+1
source

I just attach the httpCode property to the error object. KISS

0
source

Source: https://habr.com/ru/post/958879/

More articles:


All Articles