Avoid swallowing thrown errors

[Tauren Mills]

It looks like FuturesJS is swallowing any errors that I'm throwing in
my application. I typically throw errors when something critical has
happened that makes it so the application cannot go on. I just
realized I was no longer seeing these errors because they were getting
swallowed by futures.js. For instance, my application does this:

if (!(component instanceof "Component")) {
throw new Error("Only component objects can be added");
}

The following catch is swallowing this error (line 83 of futures.js
from a few days ago):

(deed === 'fulfilled' ? waiting : dreading).forEach(function
(func) {
try {
func.apply(func, outcome);
}
catch (ignore) {}
});

Since FuturesJS throws errors internally, perhaps it should test for
its own errors, and then rethrow other errors. For instance, here's
some rough untested code:

// Declared in futures.js
function FuturesException(params) {
$.extend(this,params);
}

// When futures.js needs to throw an error:
throw new FuturesException({
name: "Something",
message: "Some error occurred"
}

// When futures.js is catching an error:

try {
func.apply(func, outcome);
}
catch (e) {
if (!(e instanceof "FuturesException"))
throw e;
}
// do whatever
}

[AJ ONeal]

I think you're absolutely right.

If you would like please implement the change and send me a pull request (as described in the TestCases email).

Otherwise I'll look into that this evening. Seems like a quick fix.

AJ ONeal

--
Please use prefixes: [Pony] Feature requests, [TestCase] Test cases, [Bug] if you're lazy. If you have contract work or position for FuturesJS devs, prefix [Bounty] or [Job].
-----
To post to this group, send email to futures-j...@googlegroups.com
To unsubscribe from this group, send email to
futures-javascr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/futures-javascript?hl=en

[AJ ONeal]

I changed it for now, however, that is part of Crockford's original implementation. The reason being that if you're using functions from multiple libraries and one of them throws an error, do you want to prevent the execution of all other functions in the queue?

Perhaps this is something that should throw in the development package, but not in the production package. 

What do you think?

For the other case where I'm throwing the BreakWhilst. In that case it does make much more sense to handle that exception very separately.

Thanks so much for your feedback Tauren. Keep it coming.

AJ ONeal

On Thu, Jul 22, 2010 at 10:42 AM, Tauren Mills <yowz...@gmail.com> wrote:

[Tauren Mills]

AJ,

Thanks for taking care of this. I've just updated to the latest and will let you know if I run into anything else.

I changed it for now, however, that is part of Crockford's original implementation. The reason being that if you're using functions from multiple libraries and one of them throws an error, do you want to prevent the execution of all other functions in the queue?

If a 3rd party library I'm using throws an error, I'd like to see the error and be able to handle it. Hopefully it would only throw errors that are show-stoppers anyway, so would it matter that the next functions in the queue don't run? Maybe I'm just not understanding your point. Can you illustrate what situations this would cause a problem for? As far as Crockford's implementation goes, I would assume his was a barebones implementation to get the concept across, not necessarily production quality code.

 

Perhaps this is something that should throw in the development package, but not in the production package. 

I'm not sure about that. Maybe when I understand the issue better, I will be able to give an opinion. At the moment, it doesn't seem wise to catch and swallow non-FutureJS exceptions, even in production. My application may be designed to elegantly handle exception situations, but it would never know about them if FJS swallows them.

For the other case where I'm throwing the BreakWhilst. In that case it does make much more sense to handle that exception very separately.

Yes, that is good. When I create a library, I have internal exceptions as well as external exceptions. The internal ones are always consumed and handled by the library. This lets my library detect issues related to its functionality and deal with them. If the error is something the library can't handle on its own, then I throw an external exception. The calling code needs to handle those exceptions. I would assume most 3rd party libraries do the same, but perhaps I'm mistaken.

 

Thanks so much for your feedback Tauren. Keep it coming.

 

No problem. I'd like to contribute more, but my time is very limited. I will do what I can.  

I'm very interested in your take on the two CommonJS proposals (A and B). I don't have the time to really look into them, and your project was esy to get up and running quickly. Plus, FJS seems to have more features that could prove useful. But it would be great if everyone could work together to produce a single comprehensive library for promises, futures, etc. Or at least API compatible versions so that we could more easily swap out libraries without lots of client-code changes.

Thanks again for all your work on this!

Tauren

[AJ ONeal]

No problem. I'd like to contribute more, but my time is very limited. I will do what I can.  

Same here. This isn't my day job... yet...

 

I'm very interested in your take on the two CommonJS proposals (A and B). I don't have the time to really look into them, and your project was esy to get up and running quickly. Plus, FJS seems to have more features that could prove useful. But it would be great if everyone could work together to produce a single comprehensive library for promises, futures, etc. Or at least API compatible versions so that we could more easily swap out libraries without lots of client-code changes.

I subscribed to the CommonJS list. I have a few goals for the framework that I'd like to accomplish - namely async method queuing and perhaps curry-ing, but the next step after that is for me to take a good hard look at the proposals, draft some use cases, and see what I feel is on target and I should update and what I feel doesn't support the use cases well and provide some feedback to them.

 

Thanks again for all your work on this!

Thanks for using it. Put up a blog post when you get a chance. As we all use it we'll narrow down the best use cases and get the bugs out and have a great library for the community.

 

AJ ONeal