It is best giving as much detailed and correct information about errors to user.
Err: Unable to delete blah.txt, quitting. This can be okay; but in case I have 1000 files to delete and I already know some are not possible to delete; but I still want to the tool to go over other files instead of quitting at first. Although it looks naive, this was how many operating systems worked until last years. Since you start delete jobs in parallel (multiple async calls?) you will get an error for the ones that did not work; but your system will continue working on the ones that can be deleted. So this is nicer. If I were developing this, as first step, I would throw a text message for every error: "Err: Unable to delete blah.txt" without being very nice to user. If it is a library used by another software, I would simple pass error object to caller. In Node, it would be best designing this system as an EventEmitter and letting users to bind on error event if they want to take care of it or simply ignore if they don't care. If I had more time to continue working on this for a few more hours, then I would do the combined and more meaningful error reporting. If it is used by people, it would be something like "1201 files deleted, 114 were skipped. Type "D" to see more details, "Q" to quit..." On a web interface or another kind of GUI, I would make details hidden but easy to see with just one click. If it is a library that is used by other software, for me, it is all about providing good alternatives and fallback solutions. I would allow an "error" handler which would be triggered for every single error. When I have more time, I would also add "end" or something like that as another event. In this last object, I would provide stats like the folder that we processed, total number of files processed, total number of failures, total number of success, success/failure ratio etc. The more time I have and the more thing users demands, the fancier I would go. For such stats, it would have an effect on performance so it is another thing I would carefully design the default behavior. I would skip the ones that needs too much work for processor and require some parameters explicitly set to enable those. Other things like the folder name, I would keep them as default. I hope I have not written completely unrelated to your question. :) On Thursday, July 5, 2012 11:44:45 AM UTC-4, Alan Gutierrez wrote: > > Let's say that somewhere within your library, you delete the contents of a > directory in parallel. Let's say all the files in a directory are > read-only so > all your parallel requests return an error. > > If you've exposed a Node.js style asynchronous function with an `(error, > result, > result...)` callback, how do you report multiple errors to person who > called > your library? Do you wrap the multiple errors in a single error, maybe > having an > array of `causes`? Do you note that multiple errors may be returned? > > Are the functions in the Node.js API that might return more than one error > that > I could study? Do any of the event emitters in the Node.js API emit a > series of > errors, or is it just one error prior to entering an error state? > > -- > Alan Gutierrez - http://twitter.com/bigeasy - http://github.com/bigeasy > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
