On Wed, Oct 29, 2014 at 4:22 AM, Simon Hengel
Hi Michael,
Personally, I think it will be nice to be able to quickly identify the constructor of the exception. Currently one has Google for the error message and hope for the best.
Thank you for pointing that out. As it happens, that's the exact conversation Chris and I had which led to this email ;).
Same thought here, one of my main complaints about the current state of exceptions is that the default exception handler gives you no hint about the type of uncaught exceptions.
For me uncaught exceptions are a programming error and I want output that helps me as a programmer to fix that programming error. I don't care about "user-friendly data display" here.
I think given the nature of hierarchical exceptions there is currently no generic way to show the exception type if the exception is at depth < 1 in the tree (for uncaught exceptions in Hspec I use the code at [1], which is better than using show but still not ideal).
For this reason I *always* derive the Show instance if I define an exception type + I would prefer if Show instances for other exceptions would be derived, too (where possible).
Would this proposal address this issue? How exactly? Could we just fix the (in my perspective) "broken" Show instances for standard exceptions instead?
We're coming from opposite ends on this one. I'm often writing user-facing applications, where a failure message of `FailedConection "www.example.com" 80` is bad, and "Unable to make a connection to www.example.com on port 80" is good. Both user-friendly and programmer-friendly display make sense, they're just different use cases. And currently, they're shoe-horned into the same `Show` instance. As long as we're all in agreement that I'm not making a real proposal, here's a solution to the problem: more methods! What about adding: displayException :: e -> String rawException :: e -> String -- meant to be the "serialized" version like derived Show instances verboseException :: e -> String -- include module the type is defined in, its package, data type, etc We can give all of these default implementations as well. The downside is that every possible usecase someone comes up with needs to go in Exception, which doesn't scale past a certain point. The question then becomes: have we already identified all of the use cases we care about? A completely different approach that might be better for your use case *and* might be useful in other cases would be to keep a stack of the `TypeRep`s we converted through when creating the SomeException. However, that would require a breaking change to SomeException, which I really *don't* want to propose. Michael