Benchmark switching to anyhow

[joshtriplett]

anyhow::Error is smaller than Box<dyn Error>; it pulls some tricks to store itself in one pointer rather than two. It's also more convenient to use; for instance, anyhow::Result<T> is an alias for Result<T, anyhow::Error>, and anyhow::Error already implies Send and Sync so you don't have to specify them. And anyhow will make it easier to provide additional context on errors.

You might consider switching code that currently uses Box<dyn Error> (or similar), and benchmarking to see if it has any performance impact. (Even if it doesn't provide a noticeable improvement, if it doesn't cause a regression it'd probably still be worth switching.)

[Byron]

For libraries, I would prefer keeping quick-error, but possibly box big enum variants to keep the size small, allowing users of these functions to actually see what went wrong programmatically.

There some spots in the code that use Box<dyn Error + Send + Sync>, but it's portions of code that don't have anyhow available, and I would like to avoid that dependency unless truly, truly required.

gitoxide-core and higher use anyhow as they are considered application level.

Unless there are performance issues, I would avoid switching just because I am so happy with the error handling story in this project so far. And I have tried a lot :D - and feel like I finally arrived.

[joshtriplett]

I absolutely agree that library code should not use anyhow. (You might consider thiserror as a more convenient replacement for quick-error with some additional features, but that's more a matter of taste.)

I was purely talking about contexts where you currently use boxed errors.

[Byron]

thiserror I evaluated, and then I found quick-error in an old project of mine and realized that these 200ish lines of macro is all I need. thiserror pulls in a bunch of dependencies and increases compile times to the point where I can't justify its benefits.

Some of my decisions are driven by my constraints, after all I am working on a tiny machine (MB Air 2020, 8GB of RAM, 4 cores) :D. It's a good thing, and I will hold on to it for that very reason and resist the urge to go all 'ARM' ;).

[joshtriplett]

@Byron Did you evaluate that before or after the change that made build-time-only dependencies use opt-level 0?

[Byron]

I don’t think so. Now that there are a few new small crates, it would be easy to test out. I am hesitant though because thiserror will never be competitive in terms of compile times, and I don’t know what it’s benefits are compared to quick-error. Maybe this is also off topic since the original issue was about anyhow, but it’s ok to me to discuss the error handling as a whole as well.

…

Sent from my iPhone

On 14. Aug 2020, at 23:51, Josh Triplett ***@***.***> wrote:  @Byron Did you evaluate that before or after the change that made build-time-only dependencies use opt-level 0? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Byron]

I have just added thiserror for use in one particular error type, resolving some limitations of quick-error in that particular instance. It's very nice, too, here my highlights (and for when I will use it):

• support for generic errors (and I will revise some error types in git-odb which could benefit from that)
• support for 'transparent' errors - often I find myself adding a quite generic 'quick-error' display message because the detailed message is contained in the source(). There I doubt the generic message adds much value most of the time.

The drawbacks of thiserror clearly is the dependency chain, which one pays once, and probably most projects do pull syn and procmacro2 in one way or another.
So in short, I think it's worth using when needed, for these features alone.

Right now it seems I will keep using quick-error, but switch to thiserror for particular Errors that require its additional feature set.

[joshtriplett]

Closing this for now, since performance-critical cases already do this. There might be value in switching, but not for performance.