Review issue and discussion around "catch anything"

[seancorfield]

See scgilardi#46 and scgilardi#24

[seancorfield]

I've been experimenting with this issue, and I think I have a new solution that addresses both the "unexpected" behavior and retains the existing Slingshot behavior (unwrapping exceptions, catching data). Essentially the transform from catch clauses to cond clauses now adds additional cond clauses for any class selector and tests against the wrapper instead of the (unwrapped) object.

This makes it possible to catch Exception e and get the ex-info that is thrown, which makes try+ more compatible with try. I believe that behavior allows for Slingshot's try+ to be a direct drop-in replacement for try which is not true today.

Does this sound like a sane approach? (testing the thrown object first against each catch clause and then also testing the wrapper object against each clause that is a class selector)

[seancorfield]

I don't think scgilardi/slingshot#46 really addresses scgilardi/slingshot#24 and I don't see much value in what is, effectively, an alternative syntax to catch Object o, so I'm not going to pursue that PR further.

[seancorfield]

My proposed approach could potentially change the behavior of existing code:

• you have a catch Exception -- which catches regular exceptions but not ex-info or wrapped exceptions
• you have some selector-based catches
• you deliberately let some ex-info and/or wrapped exceptions "escape" and percolate up the call chain

My proposal would catch those "deliberate escapes" -- because after checking the existing catch clauses, it would add the Exception check on the wrapper itself and would therefore catch those.

Because of that, I think I'm going to add some sort of option/dynvar to allow users to disable the new behavior, but I do think it should be the default.