question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Error handling consistency/conventions

See original GitHub issue

I ran into this a while back and never raised it, but since I’m here and contributing to the error handling code (#128 #126 #118) I thought I’d bring it up now.

Errors should be instanceof Error

I would have expected the errors provided in the catch(err) callback to have been instanceof Error, as is suggested by the MDN docs for Promise.reject(reason):

For debugging purposes and selective error catching, it is useful to make reason an instanceof Error.

Indeed the convention for the continuation-style callback passing cb(err) is widely recognised, supported and provided by module authors (supporting material: 1,2).

Error handling should be consistent

In debugging and fixing #126, I discovered different error handling strategies for:

The difference being that the error response json is parsed in the RPC request, but not the others. I believe that this inconsistency was introduced by accident rather than design (in the fix to #108).

Solution

I think the solution should be to extract the error construction into a common function that is used by each request type. This will ensure consistency between request type.

The error constructed should be an Error object, and I see no reason why the information that is attached to the current non-Error object format could not be attached.

For example (just a quick sketch, not an exhaustive solution), something like:

var buildCustomError = function (error, response) {
  var msg;
  if (response) {
    try {
      msg = JSON.parse(response.text).error_summary;
    } catch (e) {
      msg = error.message;
    }
  }
  var err = new Error(msg);
  err.status = error.status;
  err.response = response;
  return err;
};

Let me know what you think. I’d be happy to put together a PR that implements this solution, or leave it with you to implement. Cheers.

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:2
  • Comments:6 (3 by maintainers)

github_iconTop GitHub Comments

2reactions
good-llycommented, May 31, 2017

would be very nice to see error handling in some /example

0reactions
greg-dbcommented, Nov 13, 2020

We’ve updated the error handling in release v8.0.0, and added a note to the Upgrading document. Please upgrade to the latest version and let us know if you’re still seeing any issues. Thanks!

Read more comments on GitHub >

github_iconTop Results From Across the Web

Maintain Consistency and Adhere to Standards (Usability ...
In most cases, maintaining consistency and meeting user expectations will outweigh breaking a convention.
Read more >
Guidelines for consistent exception handling - Samir Bellouti
Exception handling is an essential concept in object oriented programming. It permits us to indicate program or method failure in way that ...
Read more >
Better error handling in JavaScript | by Iain Collins - Medium
What's so great about having conventions for errors is it makes it easier to handle specific errors well because they have explicit and...
Read more >
Error Handling – Error Codes, Exceptions and Beyond
This is the technique used by operating systems and most libraries. Historically, these systems have never been consistent or compatable with other conventions....
Read more >
Improper Error Handling - OWASP Foundation
Another valuable approach is to have a detailed code review that searches the code for error handling logic. Error handling should be consistent...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found