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

Helper for wrapped errors #2

Open
meaku opened this issue Jan 19, 2015 · 4 comments
Open

Helper for wrapped errors #2

meaku opened this issue Jan 19, 2015 · 4 comments

Comments

@meaku
Copy link
Member

meaku commented Jan 19, 2015

Sometime it's useful to catch some known errors and convert them to erroz-errors. Unfortunately those errorz-erros have the stacktrace of erroz-creation. It might be helpful to add an option to pass an original error when creating an erroz-error instance to append the original error.

Something like:

var ParseError = erroz({
  statusCode: 400,
  status: "fail",
  name: "ParseError",
  code: "parse-error",
  template "Could not parse %what"
});

try{ 
  JSON.parse("xaz--");
}
catch(err) {
   //pass original err as second argument (optional)
   errozErr = new ParseError({ what: "ever" }, err); 

   console.log(errozErr.stack) //would equal err.stack    
 }

Although it seems convenient it's also confusing as the stack is not pointing to the real "throw" . Maybe it's possible to merge the stacks or introduce a second originalStack attribute.

@jhnns
Copy link
Member

jhnns commented Jan 20, 2015

Mhmmm ... I'm not sure about this.

These should probably stay to different errors. The first error is an internal parse error that doesn't know the context, and the second one is the "public" error that is printed to the user. Imho it's ok that these are two distinct errors.

@meaku
Copy link
Member Author

meaku commented Jan 20, 2015

It's just pain in the ass if you're using a global error handler which catches all unhandled errors and swallows the actual stack. But maybe we should leave it to application logic..

@jhnns
Copy link
Member

jhnns commented Jan 20, 2015

In any case the application needs to catch the error before it is passed to the global error handler, so I don't see the benefit here.

@meaku
Copy link
Member Author

meaku commented Jan 20, 2015

It's a few lines less to write. And that's it. ™️

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

No branches or pull requests

2 participants