New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE - Errors should be different subclasses or have a code attached to them #695
Comments
Sure, this would be a good enhancement. Perhaps as a model look at how http://npm.im/restify subclasses http://npm.im/verror into different error types. |
In order to better support this project and its new group of collaborators under a new org we are trying to clean up and close issues older than 6 months. Your issue may have been fixed since the issue was open, however, if you are still experiencing a problem please re-open this issue and we will label it accordingly. |
This is still a useful RFE in my opinion as parsing the strings in error messages is a bad interface and an interface should provide a way to differentiate between classes of errors. When I look at the code I still only see new Error(), no subclassing or codes attached so I do not think this has been fixed. Please reopen this issue. |
…usly where they're uncatchable." This reverts commit 6a3ccf6.
@bpytlik I'll reopen this if you're willing to open a pr to tackle this. |
This should get fixed by #538 |
Redis error codes got added. |
As far as I know, if you want to handle different classes or errors coming out of node redis differently, you have to parse the error strings. For example, if I want to treat an error caused by the redis DB still loading off disk differently than I want to treat an error caused by the host being unreachable, I have to run regular expressions over the text of the error messages. That text is not a stable interface from what I can see.
There are two ways I can think of to solve this problem (and I'm sure there are many others):
This would make integrating node_redis into a larger program much easier as handling the errors would use a stable interface rather than a long text string.
If I've missed some existing mechanism to distinguish between errors, please let me know.
The text was updated successfully, but these errors were encountered: