How to let a thousand flours bloom

[withoutboats]

Der Fehler is intentionally limited to a predefined set of APIs that I picked when I started working on it, and I'm not interested in adding more to it - such as APIs to enable other patterns of constructing errors. It's also very actively "my" library, and I intend to release it as 1.0 soon and after that make only superficial future changes to it.

But a goal of the project is definitely to pull the ecosystem back toward the Error trait, rather than failure::Fail. I want other people to write other crates for their own error handling patterns that they like. I want to write the next iteration of this guidance with more than 4 patterns, linking to several different crates. I want this project to encourage experimentation by other people in their own libraries, to find other patterns.

Along similar lines, it's been pointed out in #12 that throw and throws in particular could make a lot of sense as an independent no_std library. And in #4 we've discussed another pattern that I've always liked (an error and errorkind pair), but that doesn't get used because it involves a lot of boilerplate. Maybe before releasing a 1.0 of this library, I should actually be releasing several libraries at the same time, to encourage a precedent that this isn't some all-encompassing solution.

[withoutboats]

I have not forgotten den Fehler :)

This library can be divided into two parts:

• A bunch of macros implementing psuedo-"throwing function" syntax
• A successor to failure but with the std Error trait

@dtolnay's crate anyhow is basically the second of these things, and there's no reason to duplicate that work. And the first of these is totally no_std compatible, unlike the second.

So basically my todo list here is to strip out all of the stuff that just duplicates the behavior of anyhow, then make the library no-std compatible. Der Fehler will be just for throwing function macros and nothing else.

[yoshuawuyts]

@withoutboats big agree on that direction!