Skip to content

Conversation

@fschoenfelder
Copy link

Hey,

we have implemented a model plugin to handle errors. It's necessary for this, to get request errors (e.g. timeout/crossdomain) and return them on the "end" of a request.
Furthermore it's possible with this modification to manipulate the error info/data that is passed to the model callbacks (e.g. save( function(err){} )).

Perhaps this was something you meant with this issue (#8) also?
I'm excited about your feedback!

Frank.

@timaschew
Copy link
Member

please give some feedback, btw who is the maintainer?

@vendethiel
Copy link
Member

It seems @juliangruber is :)

@juliangruber
Copy link
Contributor

i'm not the only one :P see https://github.com/component/model/graphs/contributors

@timaschew
Copy link
Member

so @ianstormtaylor what you think ;)

@ianstormtaylor
Copy link
Contributor

sounds interesting, but i dont quite understand the use case. would you really want a single function to handle all types of errors? i havent run into the need for this, but havent been dealing with errors much

@fschoenfelder
Copy link
Author

You're right. One option is to handle all errors in the 'toError(fn)' function.
It is also possible to handel errors by case.
For example to convert or 'refine' an error before it is passed/returned to the callback (e.g. Model.get(cb) - static.js:196).
Another option would be to notify about the error in toError(fn), e.g. by emitting the error, and handle it for a model object or static.
In our case, we use an own model plugin to handle errors either by a central error handler or by using the callback 'err' param and wrap some error handling code.
In my opinion there are be several different usages when it's possible to 'inject' some code in the model internal error handling process.

@clintwood
Copy link

+1, this is something I use (and one of the reasons for my own Model implementation)...
Essentially what @fschoenfelder is saying, injecting common error/response handling per model type allows pre-conditioning of response data or errors in one place before handing back to the normal local response handling function... @ianstormtaylor, many use cases...

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

Successfully merging this pull request may close these issues.

8 participants