Skip to content
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

Error Codes #206

Closed
jogly opened this issue Jun 22, 2013 · 5 comments
Closed

Error Codes #206

jogly opened this issue Jun 22, 2013 · 5 comments

Comments

@jogly
Copy link
Collaborator

jogly commented Jun 22, 2013

This may be a sizable undertaking, but I think should be considered. I've come across a situation in which one particular error of a few that may be returned by ORM is OK. However, the only way to identify that error is by the string message. There should be some other more stable identifying piece of information such as an error code, in addition to the messages.

@dresende
Copy link
Owner

Can you show me an example of such error?

@jogly
Copy link
Collaborator Author

jogly commented Jun 23, 2013

Gladly :)

For example, the Model function get(id, callback) can throw a few errors, some of which are, missing callback; key length mismatches; or, my allowable error, a not found error. The only identifiable information available is the "Not found" string in the error object. One solution is to extend the error object into a generic ORM error object that will contain the message and a code.

var ORMError = function(msg, code[, constr]) {
    Error.captureStackTrace(this, constr || ORMError);
    this.message = msg;
    this.code = code;
};

util.inherits(ORMError, Error);

Now, we can use throw new ORMError("Same message", NEW_CODE);, or create reusable errors:

var NotFoundError = function(msg) {
    this.super_.call(this, msg, SOME_CODE, this.constructor);
};

util.inherits(NotFoundError, ORMError);

This is something that could be phased in without affecting any existing code since every custom error will already effectively be an error.

@dresende
Copy link
Owner

Ok, I clearly see your point. You would like to have a way of distinguishing the errors without parsing a string (that might change). We have to identify them and create codes for them, perhaps having a global orm file with the list of codes (that people can lookup) and orm will use. I have to create a basic one, perhaps starting with the Model.get.

@dresende
Copy link
Owner

There should be more missing errors there, I have to change all of them. If you find any, feel free to change it.

@dresende
Copy link
Owner

I think I added most of them. If you find any please reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants