Improve Show instance of Effectful.Error.Static.ErrorWrapper

[arybczak]

For example, if a third-party library spawns worker threads and if a job throws, it simply catches SomeException, logs it and retries the job later, as of today internal exceptions representing errors of the Error effect wouldn't show any info about the error, just the backtrace.

This fixes it at the cost of small API breakage.

TODO changelog

[torgeirsh]

@arybczak Is there a way to avoid catching ErrorWrapper in such a scenario? There doesn't seen to be a predicate similar to isSyncException, and the type isn't exported for pattern matching. As a workaround, I'm parsing the output of show while ignoring the screaming voice at the back of my mind. :)

[arybczak]

I'm parsing the output of show

Umm, that's bad. Why?

[torgeirsh]

Yes, like I said it's a workaround. Is there a better way?

[arybczak]

Yeah, but why do you need to do that? I need to know the use case to suggest a solution (or improve the library).

[torgeirsh]

Oh right. It's a similar situation to the one you described, where an existing application catches SomeException for logging purposes, with the unfortunate side effect of intercepting Error effects. The least intrusive solution seems to be modifying the exception handler to catch "SomeException, except when it's an ErrorWrapper", similar to how catchSync works.

[arybczak]

Hmm. I could in theory change ErrorWrapper to be marked as asynchronous exception (since it's an internal implementation detail), so it's not caught by catchAnySync, but I'm not sure if it's a good idea.

[torgeirsh]

I like the idea! It's a white lie, but benefits from existing awareness about the perils of catching asynchronous exceptions.

[ocharles]

One place where this is unfortunate is wrapping a Hedgehog effect. For things like failure, Hedgehog would normally use Left, so when we wrap that in effectful, it becomes a throw. However, Hedgehog also has evalM which uses try. But now in an effectful world if I surround a block of code that uses failure with evalM I lose the accurate stack trace at the point of failure and instead get a stack trace at the point of evalM! Even worse is it uses the show instance for the exception, which now talks about this mysterious ErrorWrapper. Plain hedgehog has none of this, and would simple report from the location of failure. It's the very general try in evalM that is the problem and I can't really see an alternative, but it is an unfortunate wart I get when I try and lift Hedgehog's Test into effectful

[arybczak]

Ok, I created #283. I'll let it sit for a while and think if this change has a potential to blow up in our faces.