Apologies; I did not attempt to execute the code but only read the implementation of Exceptional.Normalize.normalize/{1,2,3}, and mis-read line 80, thinking that it was still part of the case-statement body that starts at line 78.
So, after experimentation, I now know that:
- Exceptional does handle the case of ‘having a stack trace’ as third element of an
{:error, problem, trace}tuple. - Other kinds of ok and error tuples, like for instance
{:error, problem, explanation, trace}and as you mentioned{:ok, value, meta}are not handled by the library (although you can indeed pass in a custom function to handle them).
Interestingly, for instance the new Mint HTTP client library frequently (a) uses more than two elements in its return values (because, amongst other things, it has to pass the altered conn object back to you) and (b) uses return types like {:error, conn, reason} and {:error, conn, reason, [responses]} in some places, which would not be handled by Exceptionals method of operation either. (For these two examples it would create an %ErlangError{original: conn})
Explicit pattern matching is a solution, but I would argue that you have more freedom if, for these ok/error tuples you match on the fields you need rather than also restricting the size of the tuple.
Please do! (and thanks for all your comparison examples by the way). It looks interesting, and I think that having more different flavours of error-handling libraries would help people.
Yes, facilitating this is exactly the goal of the library 
.
