Conversation
e2f33d7 to
0a03c11
Compare
Add an `errors` example that creates and prints various error types from the crate. This is useful for two main purposes: - Helps us catch mistakes by exercising error paths. - Helps us check that error output is useful for debugging. - Helps us check that output for "alloc" builds is good/useful (no-std) Run with appropriate features to verify the output, e.g., `cargo run --example errors --no-default-features --features=alloc`
0a03c11 to
61b6300
Compare
|
Hmm, concept ACK 61b6300. I think in practice this'd be pretty hard to keep in sync with the actual error types. Maybe it should be a collection of unit tests rather than examples? |
|
Its only about the "meaningfulness" of the error messages, I couldn't think of a way to test this except look at it every now and again. Once we are happy I don't think it will matter if some are missed, since devs will tend to copy the error style currently there. |
|
Ok, makes sense. After running the example all the error messages look great to me except that we should drop |
|
Sweet! Thanks for running them. |
Remove the 'code=' and just write the character in single quotes.
|
Do you want this to be merged? |
|
Maybe just leave it here and I'll have a go doing it in another repo, then see if it feels like its worth having. I'm not 100% sure it won't just sit and rot never to be touched again. |
Add an
errorsexample that creates and prints various error types from the crate. This is useful for two main purposes:Run with appropriate features to verify the output, e.g.,
This example is prone to go stale, is it useful? I could not think of any other way to verify that our error output was good (in both std and no-std environments).