search for: typederrorinfo

...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 T...

...to this). The big difference is that you're not trying to find "the matching handler" in the set of options. Instead, the list of handlers is evaluated in order until one is found that fits, then that handler alone is executed. So if you had the following: class MyBaseError : public TypedErrorInfo<MyBaseError> {}; class MyDerivedError : public TypedErrorInfo<MyDerivedError, MyBaseError> {}; // <- MyDerivedError inherits from MyBaseError. and you wrote something like this: catchTypedErrors(std::move(Err), handleTypedError<MyBaseError>([&](std::unique_ptr<MyBase...

...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 point...

..., but I was looking at > it in the context of LLVM internal use, so just like our RTTI is not an > option for “generic RTTI” but fits our need, we could (not should) do the > same with ErrorHandling. > > > > 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, whi...

...it in the context of LLVM internal use, so just like our RTTI is not an >> option for “generic RTTI” but fits our need, we could (not should) do the >> same with ErrorHandling. >> >> >> >> 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...

...t also contains a 'Checked' flag, initially set to false, that tracks whether the error has been handled or not. If a TypedError is ever destructed without being checked (or passed on to someone else) it will call std::terminate(). TypedError cannot be silently dropped. 2. A utility class, TypedErrorInfo, for building error class hierarchies rooted at 'TypedErrorInfoBase' with custom RTTI. E.g. // Define a new error type implicitly inheriting from TypedErrorInfoBase. class MyCustomError : public TypedErrorInfo<MyCustomError> { public: // Custom error info. }; // Define a subclass...

...a serialization routine for all possible std::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; }; Now you just describe serialization/deserialization for each error when you define it. :) (Yes - this hand waves over deserialization. It's solvable. The gory details will add nothing to this discussion). &gt...

...u know at the point where the error is raised. > > But you do in the diag handler. For example, if you are trying to open > multiple files, some of which are bitcode, you know to ignore > InvalidBitcodeSignature. > > > > 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. > > ... > > > By co...

...::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 -------...

...'Checked' flag, initially set to false, that tracks whether the error has been handled or not. If a TypedError is ever destructed without being checked (or passed on to someone else) it will call std::terminate(). TypedError cannot be silently dropped. >> >> 2. A utility class, TypedErrorInfo, for building error class hierarchies rooted at 'TypedErrorInfoBase' with custom RTTI. E.g. >> >> // Define a new error type implicitly inheriting from TypedErrorInfoBase. >> class MyCustomError : public TypedErrorInfo<MyCustomError> { >> public: >> //...

...on-null error-pointer. The cost of constructing a failure value is just the cost of constructing the pointee describing the error, plus the cost of handling the error (if that happens). The pointee must be a user-defined class that works with the typed-error RTTI system. We provide a utility class, TypedErrorInfo, to make it easy to construct such classes: class MyError : TypedErrorInfo<MyError> { ... }; User defined error classes must also implement a log method to render the error to a stream, however this can usually be done in a couple of lines. Since we expect the number of user-defined error c...