You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
generateError should generate own type of Errors #455
Hi,
orm should throw its own type of Errors.
Only distinguishing by err.code is not enough - some other layers of the application might throw the same codes.
This is related to #206 - and thanks to this, it is almost trivial now.
I can't think of a way the "client" code would break, since at worst, people doing checks against err.code won't be disappointed, and people doing err instanceof Error (this is nonsense) will get the same behavior as well.
Oh you forgot the "name" property: it is very useful to set this.name = "ORMError" - it allows checking the type without having to require the file it is declared in.
The 7776339 solution had an incorrect .stack and the way errors were constructed was a bit unintuitive. I'm not really sure if we need numerical error codes at all for anything, but they have to stick around for historical reasons. Anyways, I reimplemented it with all the bells and whistles, as well as an accurate stack & tests.
Activity
kapouer commentedon Feb 19, 2014
Nothing like a good documentation about the matter :)
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error#Custom_Error_Types
dresende commentedon Feb 23, 2014
👍
Adds ORM own type of errors (#455)
dresende commentedon Feb 23, 2014
Please comment, I don't have much time. Will current code somewhat break? We should add some kind of tests.
kapouer commentedon Feb 23, 2014
I can't think of a way the "client" code would break, since at worst, people doing checks against
err.codewon't be disappointed, and people doingerr instanceof Error(this is nonsense) will get the same behavior as well.Oh you forgot the "name" property: it is very useful to set
this.name = "ORMError"- it allows checking the type without having to require the file it is declared in.dxg commentedon Feb 24, 2014
The 7776339 solution had an incorrect
.stackand the way errors were constructed was a bit unintuitive. I'm not really sure if we need numerical error codes at all for anything, but they have to stick around for historical reasons. Anyways, I reimplemented it with all the bells and whistles, as well as an accurate stack & tests.dresende commentedon Feb 24, 2014
👍