3 ms·

The diversity of rust through having a lot of crates delivering fairly standard functionality is a dual edged sword. It is probably good for finding optimal lon

by acje 6y ago

The diversity of rust through having a lot of crates delivering fairly standard functionality is a dual edged sword. It is probably good for finding optimal long term solutions, but it leads to a lot of noise. This is not a challenge limited to error handling in rust. I wish there was some process to cannibalize the most useful crates. Also is it even possible to standardize error handling best practices across entirely different software components like an OS kernel, a web service and a CLI tool? OS kernel should not panic? Service absolutely should panic and restart to maintain availability and consistency if something unexpected happens (see Erlang) and a CLI tool has a human in the loop, sometimes.

steveklabnik 6y ago
> I wish there was some process to cannibalize the most useful crates. There is, and this is exactly what has been happening. Early crates showed some of the weaknesses in the Error trait, and then they were addressed. Failure was created, showed more holes, and they were addressed. Now anyhow/thiserr/other stuff have happened, and their improvements may or may not make it upstream. > Also is it even possible to standardize error handling best practices across entirely different software components like an OS kernel, a web service and a CLI tool? Some of the details differ, but it feels like we're at that point to me. > OS kernel should not panic? Service absolutely should panic ... Both of these are specific implementation choices, and some people will choose different options for each of them. It just really depends. But with Result (and to some extent, the Error trait), there are means to share the bits that make sense. The core of it is broadly applicable even if some of the details change.
dllthomas 6y ago
> Also is it even possible to standardize error handling best practices across entirely different software components like an OS kernel, a web service and a CLI tool? I agree that "what to do about errors" differs a lot in those domains (and even more in some others, like embedded). That's not a reason not to standardize - it's something the standard needs to take into account. Ideally, if I am writing a bit of code that could be in more than one of those domains, there is something standard I can do about errors that will provide sufficient flexibility to my users that I can act appropriately to the domain I actually find myself in. Without too much complexity.

by acje 6y ago

steveklabnik 6y ago

> I wish there was some process to cannibalize the most useful crates. There is, and this is exactly what has been happening. Early crates showed some of the weaknesses in the Error trait, and then they were addressed. Failure was created, showed more holes, and they were addressed. Now anyhow/thiserr/other stuff have happened, and their improvements may or may not make it upstream. > Also is it even possible to standardize error handling best practices across entirely different software components like an OS kernel, a web service and a CLI tool? Some of the details differ, but it feels like we're at that point to me. > OS kernel should not panic? Service absolutely should panic ... Both of these are specific implementation choices, and some people will choose different options for each of them. It just really depends. But with Result (and to some extent, the Error trait), there are means to share the bits that make sense. The core of it is broadly applicable even if some of the details change.

dllthomas 6y ago

> Also is it even possible to standardize error handling best practices across entirely different software components like an OS kernel, a web service and a CLI tool? I agree that "what to do about errors" differs a lot in those domains (and even more in some others, like embedded). That's not a reason not to standardize - it's something the standard needs to take into account. Ideally, if I am writing a bit of code that could be in more than one of those domains, there is something standard I can do about errors that will provide sufficient flexibility to my users that I can act appropriately to the domain I actually find myself in. Without too much complexity.