How does this work / why is this library not a bigger deal

[bluepines]

I have been struggling with disliking asynchrous error handling in nodejs, and you seem to have solved it. It would be really nice if this were adopted at the language level so that try/catch worked as expected.

Passing error as the first argument in every callback is highly undesireable in my opinion as it really messes up the flow of code, and generally makes things messier.

Anyway, just sort of astonished that somebody was able to make this work, I might have to check out your code for a bit.

Cheers

[CrabDude]

There is work to adopt this at the language level through a mechanism called domains. In essence, it maintains a link across asynchronous event sources. I won't be lobbying to get trycatch in core as it's non-performant and recommended only for development / debugging. I'm not sure what the implementation of domains looks like, but it's my understanding that it will be faster than a try/catch/throw, which are slow in Javascript.

Let me know if you have any questions about how it's done. I'm on the node list or @CrabDude (twitter & irc).

[bluepines]

Cool, very interesting. So it's just for development and debugging, but it is still awesome that you were able to implement this from the node runtime.

I feel like a lot of people think that asynchronous error handling has to be done like this:

doSomething(function(error, callback) {
  if (error) {callback(error)};
  // do something else
});

However, there is no fundamental law of asynchronous programming that says that asynchronous calls can't maintain a proper call stack. It's just a limitation of the implementation.

Plus, hand holding errors through every asynchronous function call becomes noisy after a while, it would be better to just handle errors at the most logical point in the call stack. And my last little tidbit is that you can't always trust that the function that takes a callback won't actually throw! Especially, if you or your colleagues are writing the code. So yes I would love to see some sort of unification around error handling.

On Thu, Feb 2, 2012 at 11:22 AM, Adam Crabtree < reply@reply.github.com

wrote:

There is work to adopt this at the language level through a mechanism called domains. In essence, it maintains a link across asynchronous event sources. I won't be lobbying to get this in core as it's non-performant and recommended only for development / debugging. I'm not sure what the implementation of domains looks like, but it's my understanding that it will be faster than a try/catch/throw, which are slow in Javascript.

Let me know if you have any questions about how it's done. I'm on the node list or @CrabDude (twitter & irc).

---

Reply to this email directly or view it on GitHub: https://github.com/CrabDude/trycatch/issues/9#issuecomment-3782028

[CrabDude]

I agree entirely that a lack of an asynchronous try catch, is a pretty glaring omission from core. There is, at times, very intense pushback against an async try/catch in core, but I find hacks like long-stack-traces and trycatch (which use the same hack) to be ugly and should not be necessary.

Core members seem to be content with process.on('uncaughtException'), but the glaring limitation of placing your server at the mercy of 3rd party modules, ESPECIALLY when core refuses to officially sanction modules (a good thing IMHO), is borderline absurd.

Tom Robinson gets most of the credit for the long-stack-traces to my knowledge though, and Tim Caswell certainly helped me build trycatch.

[bluepines]

Ah, so the core Node guys don't think it's that important.

I mean it's cool that you can register a callback for process.on('uncaughtException'), however you can't do much error handling once you've lost the entire context of the original error.

Honestly, I can see why the core guys might be uneasy. They (and numerous third-parties) have built all of their async function calls to pass error as the first argument, and if there is asynchronous error handling with try catch, then that all starts to look kind of silly. If they decide to change all of those core libraries to start throwing errors instead of passing errors, then it will break absolutely everyone's code.

It is more than obvious to me that asynchronous try/catch or some equivalent would be an obvious improvement. I think people think that passing errors is the "node way", when actually it's just a hack around this very shortcoming.

I would be more than happy to lobby for the inclusion of this, is the best place Node, V8, EcmaScript? It would be nice for someone to acknowledge that this is a legitimate issue.

On Thu, Feb 2, 2012 at 9:49 PM, Adam Crabtree < reply@reply.github.com

wrote:

I agree entirely that a lack of an asynchronous try catch, is a pretty glaring omission from core. There is, at times, very intense pushback against an async try/catch in core, but I find hacks like long-stack-traces and trycatch (which use the same hack) to be ugly and should not be necessary.

Core members seem to be content with process.on('uncaughtException'), but the glaring limitation of placing your server at the mercy of 3rd party modules, ESPECIALLY when core refuses to officially sanction modules (a good thing IMHO), is borderline absurd.

Tom Robinson gets most of the credit for the long-stack-traces to my knowledge though, and Tim Caswell certainly helped me build trycatch.

---

Reply to this email directly or view it on GitHub: https://github.com/CrabDude/trycatch/issues/9#issuecomment-3791566

[bluepines]

Ok, so I went and trolled through a bunch of posts in Google Groups, some that you were a part of, and I think I understand this issue better now.

It seems like domains will solve all of the issues with not having asynchronous try/catch. Userland will be free to throw errors to their heart's content. I envision that most third party libs will stop passing errors in callbacks altogether.

Kudos to you and other members of the community for articulating the importance of this issue, and it looks like everyone will be happy in the end. Or so that was my impression :)

On Thu, Feb 2, 2012 at 10:49 PM, Brad Carleton brad@bluepines.org wrote:

Ah, so the core Node guys don't think it's that important.

I mean it's cool that you can register a callback for process.on('uncaughtException'), however you can't do much error handling once you've lost the entire context of the original error.

Honestly, I can see why the core guys might be uneasy. They (and numerous third-parties) have built all of their async function calls to pass error as the first argument, and if there is asynchronous error handling with try catch, then that all starts to look kind of silly. If they decide to change all of those core libraries to start throwing errors instead of passing errors, then it will break absolutely everyone's code.

It is more than obvious to me that asynchronous try/catch or some equivalent would be an obvious improvement. I think people think that passing errors is the "node way", when actually it's just a hack around this very shortcoming.

I would be more than happy to lobby for the inclusion of this, is the best place Node, V8, EcmaScript? It would be nice for someone to acknowledge that this is a legitimate issue.

On Thu, Feb 2, 2012 at 9:49 PM, Adam Crabtree < reply@reply.github.com

wrote:

I agree entirely that a lack of an asynchronous try catch, is a pretty glaring omission from core. There is, at times, very intense pushback against an async try/catch in core, but I find hacks like long-stack-traces and trycatch (which use the same hack) to be ugly and should not be necessary.

Core members seem to be content with process.on('uncaughtException'), but the glaring limitation of placing your server at the mercy of 3rd party modules, ESPECIALLY when core refuses to officially sanction modules (a good thing IMHO), is borderline absurd.

Tom Robinson gets most of the credit for the long-stack-traces to my knowledge though, and Tim Caswell certainly helped me build trycatch.

---

Reply to this email directly or view it on GitHub: https://github.com/CrabDude/trycatch/issues/9#issuecomment-3791566

Brad Carleton Blue Pines Technologies http://www.bluepines.org 337.280.5208