Unify the error types in the nutype package

[gensmusic]

Hi,

I'm writing to you today to suggest that you consider unifying the error types for each struct in the nutype package. Currently, each struct has its own enum error type, which can make it difficult to track and handle errors.

I propose that we unify the error types into a single error type called ValidateError. This would make it easier to track and handle errors, as we would only need to handle a single error type instead of multiple error types.

I believe that this change would be a valuable improvement to the nutype package. Thank you for your time and consideration.

[greyblake]

@gensmusic Hi! Thanks for raising this.
You're not the first one who is raising this issue (another one was #43).

The primary motivation for having dedicated error types is to force users:

• To handle the error cases which are relevant and may happen
• Not to worry about error variants which are not relevant

But since there is a demand for a generic/common error type, I consider to implement some easy-to-use conversions into that common error type from specific error type.

I will keep this issue open, so I keep this in mind.
If you have any other questions/suggestions please let me know! I am very curious to hear from users and their use cases.

[DJDuque]

What are your current thoughts on this issue?

I am currently hesitating against using nutype in my projects because I don't want to "pollute" too much the public API of my library with a different error type per newtype structure. As an example, look at std::io::Error in the standard library; it is used everywhere, and some functions can only fail in some ways.

In #161 you mention that people want to customize the errors. Maybe adding a way to provide "context" to customize the error message is enough? In my experience people mostly just want to bubble errors up and print them. Is pattern matching the possible validation failure modes on a newtype common use case? Is it worth the extra complexity?

[greyblake]

@DJDuque
I am personally not a big fun of having a single error for all cases. The problem with that is that the error is going to have more variants that may even theoretically occur. Which forces users to handle them.

To illustrate this using std::io::Error analogy: if I am reading a file from a local file system I don't wanna be forced to handle ErrorKind:NetworkUnreachable because it's not supposed to occur when I am reading from a local file system.

Though I understand there are different personal preferences and different use cases. Some times just a healthy trade off needs to be made.

At the moment I working on #161, and it will be soon done.
This will enable users to use their custom errors, and if they wish they will be able to use a single error type if they want.