Trouble's with rejection

[brendanjerwin]

I know, it sounds like a personal problem...

I'm using promhx Promises and Streams as a return value for a bit of API I've built to load assets. My intent is to resolve the Promise once the asset is available, and reject the promise if something goes wrong.

The issue is that, sometimes, I need to reject the promise even before my client has had a chance to attach a handler. In those cases, an exception is bubbled up and out and my client halts.

In my use of other promises in other languages, I've learned to expect that the rejection works a lot like resolving a promise. i.e. if I attach a .then after a promise is resolved it will execute immediately. In other promise implementations I've used, adding a rejection handler after the promise has been rejected will execute that handler immediately as well. They also effectively ignore rejections if no handler is ever added.

Perhaps I just need a new mindset? Or is this a gap?

[jdonaldson]

This sounds like a gap. Even though I'm not treating errors as true values, it makes sense to save the current error state just as it would save the current value state. I'll look into it.

[jdonaldson]

Just submitted the new behavior (and a new utility method throwError which allows you to manually throw errors). Test updated and Haxelib updated.