-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I encourage people to check out my SNAFU crate [1]. I encourage creating many distinct error types (usually enums but also structs) and composing them. So much so that I advocate that you never create one specific error in more than one source location. That means that the collection of error types produces a unique trace through your program, uniquely identifying the source of the error with no runtime cost (compare this to a runtime-collected stacktrace / backtrace).
[1]: https://docs.rs/snafu/
I'll definitely be thinking about errors in a new way, so thanks!
I did find your conclusion interesting.
> a success story, look no further than the Rust compiler itself; I don’t think it would be an exaggeration to say that Rust enjoys the current popularity it does because of how good its error messages are, and how much effort was put into it.
The compiler diagnostics use a very different system than your error types. (eg https://github.com/rust-lang/rust/blob/master/compiler/rustc...). I think your approach adds a lot of value to a very generic library, but that often all or most of the reasonable users of a library will only propagate. If so, advanced error messages can be a waste of time. For example, a library for writing to the terminal will probably be used be applications that exit with an error message if a write fails, so it's best API might be an opaque wrapper around a string with a very specific error message.
> The nonsense end result of that line of logic is that you return a single boolean that corresponds to failure/success, so I assume that's not what you mean.
I frequently find that is all that is necessary, and is exactly the correct solution, not "nonsense" whatsoever. Perhaps even that boolean is overkill: an unrecoverable bug should perhaps instead log and then terminate, producing no error condition for the caller of your library to worry about attempting to recover from whatsoever. Detailed error reporting can be done without obscenely distinct error types, and in fact detailed error reporting frequently benefits from a focus on the task itself instead of trying to structure data to leave the task of actually reporting the error to someone else, and kicking the can down the road.
E.g. for parsing focused errors like this I'd be more interested in pretty printing the source line in question, underlining the error, etc. - I wrote https://github.com/MaulingMonkey/json-spanned-value for helping ease the display of bad JSON data in a manner that integrates with your IDE for ease of fixing said data by jumping directly to the cause.
And then, admittedly, there are times when different errors should be recovered from differently. When the caller might wish to retry an operation after some errors, try a different operation after other, report file+line+range information for yet other errors, etc. - these have very concrete answers to "What do you expect the user of your library to do with this detailed information?" that are not difficult to answer at all.
> Contrast the two error messages:
Both are UTF8 strings without types adding anything obviously useful. A silly demo screenshot of errors that will open the offending document if closed, and navigate to the line/column of said error:
https://github.com/MaulingMonkey/json-spanned-value/blob/mas...
Which operates by immediately dumping the "errors" to terminal without any types involved whatsoever... nor even a boolean branch! Well, a real program might set a boolean so the CLI knows to exit(1) instead of using partially parsed data...