There are different concerns here: * the __exception__ struct field is necessary for pattern matching on try/catch
* exception is called by raise. It is not for data structure polymorphism by a direct module to struct conversion * message is always necessary by any exception module as it returns the message If I understand your proposal, you want to replace the second item by a protocol. But the first bullet means that the protocol will still have to return an exception struct. Can you please confirm what the protocol would replace and what the protocol functions should return? On Tue, Apr 4, 2017 at 11:39 Michał Muskała <[email protected]> wrote: > Hello everybody, > > I was working recently a lot with errors and exceptions, and got annoyed > by the very complex way an exception works. There are so many ways to use > them, it gets very confusing. > > First there is a struct with the magic __exception__ field. The associated > module may or may not export both exception/1 and message/1 functions for > different circumstances. It's not entirely clear to me when each of them is > called. > > The purpose of all of this is clear - allow different data structures to > be used for exceptions. But the thing is - we already have a way to achieve > this kind of polymorphism - protocols. > > I propose adopting a protocol for formatting exceptions. For backwards > compatibility we could keep the Any implementation call the associated > module's message/1 function. > > Let me also briefly explain the use case that lead me to this proposal: > I'm working on a low-level library to replace (and make more flexible) the > ecto type conversions and changeset validations (loosely inspired by Ruby's > "dry" family of libraries). In case of errors, the library would return > structs that could be used in two ways - one to provide programmer-friendly > output as an exception, and the other to provide end-user-friendly output > as validation errors. > > Regards, > Michał. > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/d3986437-390f-437d-b742-599bb82b8f69%40Spark > <https://groups.google.com/d/msgid/elixir-lang-core/d3986437-390f-437d-b742-599bb82b8f69%40Spark?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BzA2GDRmCd5hd3FLA2YcNfeiwD-UBfdiEs8u6EKCBKzw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
