Pre-RFC fact finding document for 3 error handling RFCs

I'm working on 3 different RFCs pertaining to error handling

  • Generic member access for dyn Error trait objects
  • Error Return Traces
  • Differentiating Debug::fmt from Error Reporting

And I'm currently looking for feedback on the proposals so far. Right now I have them all in a single dropbox paper document that anyone can comment on.

If you're interested in these proposals and have the time I would love to get feedback on the proposals so far and Pros/Cons I've listed, any alternative solutions, or comments on any of the Unresolved Questions.


Re: member access for dyn Error, it sounds like what you want is essentially a Javascript Object?

As in, an object that can have any number of fields of any type, where coordination between the code assigning fields and the code reading them is not statically enforced?

The first thought that comes to mind is that it would inherit the attributes of a JS-style type system, both the advantages (can fail gracefully, falls back to best-effort solution if given incompatible data) and the weaknesses (leads to ecosystem fragmentation, code can silently stop working because we're using two libraries together that make different assumptions with their ad-hoc error types).

I don't think it's a deal-breaker, but I think any proposal like that should acknowledge that it's essentially trying to recreate JS objects in a localized way.

I’d like some more elaboration on the motivation. Preferably a code sample. What does this proposal allow you to accomplish that would not be possible otherwise? This whole abstract talk of ‘extracting context’ flies way over my head. I’m not saying it is not useful, I just do not understand what the problem is, and why the Error trait is the place to solve it. Why not capture and process the ‘context’ before the concrete type of the error is lost in a conversion to dyn Error?

I also don’t understand why Debug​ is supposedly used for human-readable error reporting; as I understand it, it is the Display trait which is supposed to be used for human-readable anything. Though that may be me misunderstanding the term ‘human-readable’; I’d suggest avoiding the term, and instead speaking of displaying things for the end-user and for the programmer.

JavaScript did not invent dynamic binding/typing, that’s one thing. And this proposal isn’t really that; it amounts to treating implementations of Error as carrying a read-only typemap, so there can be at most one field per type, and the structure of the type is fixed. There’s much less possibility for mischief here than in a fully dynamically-typed setting.

But it’s not like there is no potential for confusion. For one thing, different crates may disagree about what a u32 attached to a dyn Error is supposed to mean. Perhaps add a marker trait? Types in Rust are nominal, so wrapper structs can be used to disambiguate semantics.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.