- Introduce a toString(Error) function which produces a error string.
- Add a message() method to ErrorInfoBase with a sensible default implementation.
This should help reduce code duplication and simplify porting code which uses std::error_code.
Differential D19883
[Support] Add a free toString function for Error vsk on May 3 2016, 11:28 AM. Authored by
Details
This should help reduce code duplication and simplify porting code which uses std::error_code.
Diff Detail
Event TimelineComment Actions Hrm. This particular plan sounded better in my head when we were discussing it earlier. My bad. I like the idea of adding a message() method to ErrorInfoBase so that clients can write something like: std::string Msg; handle(std::move(Err), [&](ErrorInfoBase &E) { Msg = E.message(); }); And I think it'd be useful to wrap all that up in a free function like 'toString', so that you could write: std::string Msg = toString(std::move(Err)); However, unless there's a compelling reason not to, I think toString should consume the Error the same way logAllUnhandledErrors does. The only reason I can think of not to consume the error (but still to log it) is for debugging output: auto E = canFail(...); DEBUG(OS << "canFail generated an error: " << toString(E) << "\n"); // ... // Actually handle or return E. If we want to support that idiom we should introduce non-consuming variants of both logAllUnhandled and toString for consistency. Comment Actions Lang and I discusses this off-list and reached the conclusion that it makes more sense to have a *destructive* toString operation on ErrorInfoBase (not Error). That's because: 1) the whole point of Error is to enforce centralized error handling, and 2) the Error class should just handle ownership -- we already use ErrorInfoBase for log so message really belongs there. Lang's example of a use-case for a non-destructive toString method is interesting but I haven't run into such a use case in practice. So, we can defer that until it's needed. |