snafu VS json-spanned-value

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/

Yes, all procedural macros are inherently unhygienic. This has even bitten us once before.

> 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...