search for: typederror

...nships between them. My hope is that library code could use this scheme to model errors in a meaningful way, allowing clients to inspect the error information and recover where possible, or provide a rich diagnostic when aborting. The scheme has three major "moving parts": 1. A new 'TypedError' class that can be used as a replacement for std::error_code. E.g. std::error_code foo(); becomes TypedError foo(); The TypedError class serves as a lightweight wrapper for the real error information (see (2)). It also contains a 'Checked' flag, initially set to false, that tracks w...

...log(raw_ostream &OS) const override { if (!ArchiveName.empty()) OS << "In archive '" << ArchiveName << "', "; OS << "In object file '" << ObjectName << "', " << EC.message(); } }; TypedError processArchive(Archive &A) { TypedError Err; for (auto &Obj : A) { auto Err = processObject(Obj); if (auto E2 = catchTypedErrors(std::move(Err), handleTypedError<ObjectError>([&](std::unique_ptr<ObjectError> OE) { OE->ArchiveName = A.ge...

...archy (see http://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html), which means you need to know about all your potential subclasses up-front. That's not an option for a generic error class that might be subclassed in arbitrary ways. The new RTTI system uses something closer to LLVM's Pass IDs: TypedErrorInfo (a utility which all errors must inherit from) introduces a new static char for each error type and uses its address as an ID. When you ask an error value "are you a subclass of type T" (via the isSameOrSubClass method) the call goes to the parent TypedErrorInfo object, which compares...

Hi James, > It seems to me that "[[clang::warn_unused_result]] class TypedError" is probably sufficient for ensuring people check a status return value; I'm not sure runtime checking really brings much additional value there. I see the attribute as complimentary. The runtime check provides a stronger guarantee: the error cannot be dropped on any path, rather than jus...

...RTTI system is that it would let us re-use this error class in other LLVM projects (LLD, LLDB, etc) without having to enumerate their errors in LLVM. > Nice, and since this is on the error path we don’t care if it is not “as fast as” the custom LLVM RTTI. Yep. > OK got it now, the “empty” TypedError()is the key :) > (and I was using success/failure terminology reversed compare to you) Yeah - this is confusing. It's no worse than 'std::error_code()', but it's no better either. Maybe introducing a utility wrapper like 'TypedErrorSuccess()' or even 'ESuccess()'...

...turn up anything interesting. If anybody has seen other error handling schemes of note I'd love to hear about them. > On this topic of not paying the price on the non-error code path, it would be nice to not pay for constructing all the lambda captures when there is no error. If your catchTypedErrors call is under an if-test then the lambdas are in a scope that won't be entered on the non-error path: if (auto Err = foo()) if (auto E2 = catchTypedErrors(std::move(Errs), <lambdas here>)) return; I think (though I haven't tested this) that most lambdas should inline away to...

Hi Michael, Rafael, Pawel, Apologies for the delayed reply - I was out on vacation last week. > In fact I would actually support outright > replacing ErrorOr with this if it can be done safely, as I find the > name TypedErrorOr a bit long. I find the name awkward too. I'll leave these classes as TypedError and TypedErrorOr<T> when I submit the initial patch to llvm-commits, but please feel free to comment on the names in that review. If the proposal is adopted I think the eventual plan should be to move to ...

...the stack. I don't think these are really independent. Whether or not you need to emit a diagnostic depends on whether a caller can handle the corresponding error, which isn't something you know at the point where the error is raised. That's the idea behind the 'log' method on TypedErrorInfo: It lets you transform meaningful information about the problem into a log message *after* you know whether it can be handled or not. Recoverable errors can be logged (if the client wants to do so), but they don't have to be. Using TypedError for diagnostics also means one fewer friction p...

...I like this idea in general. It's a better implementation of what > ErrorOr originally was before we removed the custom error support > because it wasn't used. In fact I would actually support outright > replacing ErrorOr with this if it can be done safely, as I find the > name TypedErrorOr a bit long. The main differences are * This will hopefully be used. * TypedErrorOr is really a TypedError or T. The situation before was not that ErrorOr was std::error_code or T. Since we are adding it, I would also support replacing every use of ErrorOr with TypedErrorOr and renaming it. Ch...

...s to define custom error classes. Point (4) is addressed in my scheme by setting breakpoints on error class constructors. With a wrapper around std::error_code, the best you can do is to set a conditional breakpoint looking for construction with a particular enum value. Point (5) is a wash - both TypedError and std::error_code are cheap in the success case. One of the concerns that has been raised with my system is complexity. I don't think the system is overly complex conceptually (though the implementation does involve some non-trivial template goop). I presented the system in detail in my ori...

...::error_codes that might come up, even if they were powerful >> enough to describe everything that could go wrong (which again, being static >> kinds, they're not). With my proposal however, a JITError base class can be >> defined as: >> >> class JITError : public TypedErrorInfo<JITError> { >> public: >> virtual void serialize(RPCChannel &C) const = 0; >> }; > > What prevents you from using a diag handler in the jit server that > sends errors/warnings over the RPCChannel? > > Cheers, > Rafael -------------- next part ---...

...I agree, but I don't have strong feelings on this particular example - it was intended as a straw man. My point is that error recover is useful in general: there is a reason things like exceptions exist. Diagnostic handlers are very poorly suited to general error recovery. > > void check(TypedError Err) { > > if (!Err) > > return; > > > > logAllUnhandledErrors(std::move(Err), errs(), "<tool name>"); > > exit(1); > > } > That is not the same that you get with a diagnostic handler. What you > get is an exit after the error was...

On Wed, Feb 10, 2016 at 6:47 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > >> This highlights why I think it is important to keep diagnostics and > >> errors separate. In the solution you have there is a need to allocate > >> a std::string, even if that is never used. > > > > Errors are only constructed on the error path. There is no