Conversation
|
This should perhaps use the global I know this fixes the type safety problem, but it doesn't fix the issue of catching exceptions from pattern matches and the like. I guess that doesn't matter if we're saying exceptions are "anything that could go wrong in JavaScript land or explicitly thrown PureScript exceptions"? |
|
Does anything currently use that type? Can we move it into |
|
|
There was a problem hiding this comment.
What's the expected semantics here?
When would e not be an Error? If someone throws something that isn't in the Error hierarchy? Could we wrap that thing in an Error and handle it immediately, rather than throwing something we can't actually catch?
if (e instanceof Error) {
return c(e)();
} else {
return c(new Error(e))();
}As it is now. This is a runtime exception we can't actually handle.
Unfortunately, it's also not a matter of wrapping the library throwing the non-error and calling it a day. This check will fail in NodeWebKit, since it uses two different contexts with different prototypes. So, what is thrown as an Error on the node side, will not be an instance of the window's Error because the prototypes are different. There's no way around this prototypal difference
I understand you shouldn't be concerned with what some random library does, but I think this happens for anything with a different context, like iframes, so, this might be more painful than first thought.
|
I'm not sure I understand your NodeWebkit example, sorry. The reason I check the type is that someone might just |
|
I think he's saying there are two different |
|
Hmm. Is there any way we can identify those? Using Maybe rethrowing everything as an |
|
@garyb that's exactly it. The NodeWebKit example is just one, but any time you have more than one window you run into the same thing. @paf31, that should work for For other things, can we wrap them in a |
Resolves purescript/purescript#474