4 ms·

>I usually don't try to imagine how someone should handle the error. But that's exactly what you do when you... >... try to indicate the different types of er

>I usually don't try to imagine how someone should handle the error. But that's exactly what you do when you... >... try to indicate the different types of errors that could occur and what type of information needs to be included to be useful to the caller. Modelling the error domain means to decide which possible distinctions matter and which don't. This is not self evident. It's you imagining what users may want to do with your errors. Is it enough for the caller to know that some string you're parsing is invalid or do they need to know what it is exactly that makes it invalid? If you decide to just pass on everything you happen to know based on your current implementation then you are putting restrictions on future changes to that implementation, potentially including the use of third party libraries. What if you find a shortcut or a library that makes your parser 10 times faster but doesn't provide this detailed information? What I see a lot in Rust is that massive amounts of implementation details are leaked via errors. thiserror actually encourages this sort of implementation leak: #[derive(Error, Debug)] pub enum MyError { Io(#[from] io::Error), Glob(#[from] globset::Error), } https://docs.rs/thiserror/latest/thiserror/ https://docs.rs/thiserror/latest/thiserror/

zaphar 10mo ago
Sure, if you don't model the error domain correctly you will leak stuff that maybe you shouldn't leak. But I'm not sure that this is worse than just not exposing the types of errors that you are handling. Your example is interesting actually because there are real differences in those types of errors. IO errors are different from the globset errors. It is reasonable to assume that you would want to handle them differently. If your function can actually have both errors as a consumer I would want to know that so I can make the correct decisions in context. If you don't have a way to signal to my code that both happen you've deprived me of the tools to do my own proper error modeling and handling.
- fauigerzigerk 10mo ago
  >Sure, if you don't model the error domain correctly you will leak stuff that maybe you shouldn't leak You are implying that there is one correct and self evident set of distinctions. I disagree with that. In library design, you're always making assumptions about what users may want. In my opinion, this is even harder when modelling errors, because there are so many possible ways in which callers might want to respond. >Your example is interesting actually because there are real differences in those types of errors. IO errors are different from the globset errors. Of course. I'm not complaining about the distinction between io errors and globbing errors here but about the fact that the globset library and its specific error type is leaked. What if someone (say fastburningsushi) comes along and creates a glob library that absolutely smokes this one? :P

zaphar 10mo ago

Sure, if you don't model the error domain correctly you will leak stuff that maybe you shouldn't leak. But I'm not sure that this is worse than just not exposing the types of errors that you are handling. Your example is interesting actually because there are real differences in those types of errors. IO errors are different from the globset errors. It is reasonable to assume that you would want to handle them differently. If your function can actually have both errors as a consumer I would want to know that so I can make the correct decisions in context. If you don't have a way to signal to my code that both happen you've deprived me of the tools to do my own proper error modeling and handling.

fauigerzigerk 10mo ago
>Sure, if you don't model the error domain correctly you will leak stuff that maybe you shouldn't leak You are implying that there is one correct and self evident set of distinctions. I disagree with that. In library design, you're always making assumptions about what users may want. In my opinion, this is even harder when modelling errors, because there are so many possible ways in which callers might want to respond. >Your example is interesting actually because there are real differences in those types of errors. IO errors are different from the globset errors. Of course. I'm not complaining about the distinction between io errors and globbing errors here but about the fact that the globset library and its specific error type is leaked. What if someone (say fastburningsushi) comes along and creates a glob library that absolutely smokes this one? :P