Thank you, for your response.
There exists a major problem with the current domain module today in my
opinion.
In a synchronous control flow was try/catch invented for be able to skip
for checking for errors everywhere. Instead assume everything went OK and
if some error happen, just throw away that error and lets handle it there
it can best be handled, and if any catch statement failed, just re-throw it
and the next catch statement will handle it. Try/catch should lose must of
its purpose if it could only catch one type of error (all) and only have
one catch statement. The current design of the domain module is limited to
this, my solution not.
One other problem with domains is that you cannot receive the current
domain within the current domain context, and create a new domain from
that. , it should probably be great if anyone could do:
var context = domain.create();
context.run(function () {
//this would refer to the current domain
var fileDomain = this.create(); //instead of context.create()
require('fs').readFile("none-existent file", file.intercept(function () {
var foo = this.create(); //instead of fileDomain.create()
throw new Error("Some Error"); //caught by fileDomain
}));
});
My current module does exactly this, there this always reference to the
current "context"/"domain". Even the this keyword may not be used, but
something to receive the current domain.
And then last, it is probably better to save all domain data (in a error)
within a object, instead of multiple? Like:
error = {
domain = {
thrown: true,
//more members here
}
};
instead of_
error.domain_thrown,
//more error properties
It would encapsulate the domain data to one object instead of multiple,
decreasing the the chance of overwriting a current property in the error
object (or use it in the future).
Cheers
On Wednesday, July 11, 2012 9:00:18 PM UTC+2, Jeff Barczewski wrote:
>
> @idleman, I didn't go through in detail what you have illustrated here or
> how you plan to implement, but wanted you to maybe backup a step and
> discuss what your value proposition for this project is beyond what the new
> Node.js domains brings to the table.
>
> Any robust error handling solution needs to take advantage of the best
> hooks node.js can provide especially when asynchronous IO is involved, so
> you should take a look at the new Domains introduced in 0.8. Your solution
> should most likely use or build on Domains.
>
> http://nodejs.org/api/domain.html
>
> If domains doesn't go far enough with what you are needing/wanting, please
> identify the gaps and how your project would provide them.
>
> Also, if your needs are universal for many people, then they could
> potentially be added to domains and everyone benefits.
>
> So my suggestion is to look at domains, identify any gaps and communicate
> back to this list for input, then your framework could potentially take on
> the role of implementing those gaps on top of what node already provides
> (in domains).
>
>
> All the best,
>
> Jeff
>
>
>
>
>
--
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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
