<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 2, 2016, at 10:42 PM, Lang Hames <<a href="mailto:lhames@gmail.com" class="">lhames@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Mehdi,<div class=""><br class=""></div><div class=""><div class="">> I’m not sure to understand this claim? You are supposed to be able to extend and subclass the type of diagnostics? (I remember doing it for an out-of-tree LLVM-based project).<br class=""></div><div class=""><br class=""></div><div class="">You can subclass diagnostics, but subclassing (on its own) only lets you change the behaviour of the diagnostic/error itself. What we need, and what this patch supplies, is a way to choose a particular handler based on the type of the error. </div></div></div></div></blockquote><div><br class=""></div><div>If you subclass a diagnostic right now, isn’t the RTTI information available to the handler, which can then achieve the same dispatching / custom handling per type of diagnostic?</div><div>(I’m not advocating the diagnostic system, which I found less convenient to use than what you are proposing)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">For that you need RTTI, so this patch introduces a new RTTI scheme that I think is more suitable for errors types*, since unlike LLVM's existing RTTI system it doesn't require you to enumerate the types up-front.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>It looks like I’m missing a piece of something as it is not clear why is this strictly needed. I may have to actually look closer at the code itself.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">* If this RTTI system is considered generically useful it could be split out into its own utility. It's slightly higher cost than LLVM's system: One byte of BSS per type, and a walk from the dynamic type of the error to the root of the type-hierarchy (with possible early exit) for each type check.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">> What does success or failure means for the handler?</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">It gives the handler an opportunity to inspect and then "re-throw" an error if necessary: A handler might not know whether it can recover based on type alone, or it may not want to recover at all, but instead attach some context to provide a richer diagnostic.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">As a concrete example, one of our motivating cases is processing object files in archives. Down in the object file processing code, a load command might be found to be malformed, but at that point there's no context to tell us that the object that it's in is part of an archive, so the best diagnostic we could produce is "In foo.o: malformed load command at index N". A (straw-man) improved system might look like this:</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><font face="monospace, monospace" class="">class ObjectError ... { // <- Root of all object-file errors</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> std::string ArchiveName = "";</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> std::string ObjectName = "";</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> std::error_code EC;</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""><br class=""></font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> </font><span style="font-family:monospace,monospace" class="">void log(raw_ostream &OS) const override {</span></div><div class="gmail_extra"><font face="monospace, monospace" class=""> if (!ArchiveName.empty())</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> OS << "In archive '" << ArchiveName << "', ";</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> OS << "In object file '" << ObjectName << "', " << EC.message();</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> }</font></div><div class="gmail_extra"><font face="monospace, monospace" class="">};</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""><br class=""></font></div><div class="gmail_extra"><font face="monospace, monospace" class="">TypedError processArchive(Archive &A) {</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> TypedError Err;</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> for (auto &Obj : A) {</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> auto Err = processObject(Obj);</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> if (auto E2 =</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> catchTypedErrors(std::move(Err),</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> handleTypedError<ObjectError>([&](std::unique_ptr<ObjectError> OE) {</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> OE->ArchiveName = A.getName();</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> return TypedError(std::move(OE));</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> })</font><span style="font-family:monospace,monospace" class="">)</span></div><div class="gmail_extra"><font face="monospace, monospace" class=""> return E2;</font></div><div class="gmail_extra"><font face="monospace, monospace" class=""> }</font></div><div class="gmail_extra"><font face="monospace, monospace" class="">}</font></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">In this example, any error (whether an ObjectError or something else) will be intercepted by the 'catchTypedErrors' function. If the error *isn't* an ObjectError it'll be returned unmodified out of catchTypedErrors, triggering an immediate return from processArchive. If it *is* an ObjectError then the handler will be run, giving us an opportunity to tag the error as having occurred within archive A.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Again - this is a straw-man example: I think we can do better again for diagnostics of this kind, but it showcases the value of being able to modify errors while they're in-flight.</div></div></div></blockquote><div><br class=""></div><div>Sure, this case shows “success” of the handler, now what is a failure of the handler and how is it handled?</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">> Is your call to catchAllTypedErrors(…) actually like a switch on the type of the error? What about a syntax that looks like a switch?<br class=""></div><div class="gmail_extra"><div class="">></div><div class="">> switchErr(std::move(Err))</div><div class="">> .case< MyCustomError>([] () { /* … */ })</div><div class="">> .case< MyOtherCustomError>([] () { /* … */ })</div><div class="">> .default([] () { /* … */ })</div><div class=""><br class=""></div><div class="">It's similar to a switch, but it's actually more like a list of regular C++ exception catch blocks (the name 'catchTypedError' is a nod to this).</div><div class="">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:</div><div class=""><br class=""></div><div class=""><font face="monospace, monospace" class="">class MyBaseError : public TypedErrorInfo<MyBaseError> {};</font></div><div class=""><font face="monospace, monospace" class="">class MyDerivedError : public TypedErrorInfo<MyDerivedError, MyBaseError> {}; // <- MyDerivedError inherits from MyBaseError.</font></div><div class=""><br class="">and you wrote something like this:</div><div class=""><br class=""><span style="font-family:monospace,monospace" class="">catchTypedErrors(std::move(Err),</span><br class=""></div><div class=""><font face="monospace, monospace" class=""> handleTypedError<MyBaseError>([&](std::unique_ptr<MyBaseError> B) {</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class=""> }),</font></div><div class=""><font face="monospace, monospace" class=""> handleTypedError<MyDerivedError>([&](std::unique_ptr<MyDerivedError> D) {</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class=""> })</font></div><div class=""><font face="monospace, monospace" class="">);</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class="">The second handler will never run: All 'Derived' errors are 'Base' errors, the first handler fits, so it's the one that will be run.</div><div class=""><br class=""></div><div class="">We could go for something more like a switch, but then you have to define the notion of "best fit" for a type, which might be difficult (especially if I extend this to support multiple inheritance in error hierarchies. ;). I think it's easier to reason about "first handler that fits”.</div></div></div></div></blockquote><div><br class=""></div><div>Oh I was seeing it as a “first match as well”, just bike shedding the syntax as the function calls with a long flat list of lambdas as argument didn’t seem like the best we can do at the first sight.</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Lang.</div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 2, 2016 at 6:33 PM, Mehdi Amini <span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Hi Lang,</div><div class=""><br class=""></div><div class="">I’m glad someone tackle this long lived issue :)</div><div class="">I’ve started to think about it recently but didn’t as far as you did!</div><div class=""><br class=""></div><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Feb 2, 2016, at 5:29 PM, Lang Hames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><span style="font-size:13px" class="">Hi All,</span><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">I've been thinking lately about how to improve LLVM's error model and error reporting. A lack of good error reporting in Orc and MCJIT has forced me to spend a lot of time investigating hard-to-debug errors that could easily have been identified if we provided richer error information to the client, rather than just aborting. Kevin Enderby has made similar observations about the state of libObject and the difficulty of producing good error messages for damaged object files. I expect to encounter more issues like this as I continue work on the MachO side of LLD. I see tackling the error modeling problem as a first step towards improving error handling in general: if we make it easy to model errors, it may pave the way for better error handling in many parts of our libraries.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">At present in LLVM we model errors with std::error_code (and its helper, ErrorOr) and use diagnostic streams for error reporting. Neither of these seem entirely up to the job of providing a solid error-handling mechanism for library code. Diagnostic streams are great if all you want to do is report failure to the user and then terminate, but they can't be used to distinguish between different kinds of errors</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I’m not sure to understand this claim? You are supposed to be able to extend and subclass the type of diagnostics? (I remember doing it for an out-of-tree LLVM-based project).</div><span class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-size:13px" class="">, and so are unsuited to many use-cases (especially error recovery). On the other hand, std::error_code allows error kinds to be distinguished, but suffers a number of drawbacks:</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">1. It carries no context: It tells you what went wrong, but not where or why, making it difficult to produce good diagnostics.</div><div style="font-size:13px" class="">2. It's extremely easy to ignore or forget: instances can be silently dropped.</div><div style="font-size:13px" class="">3. It's not especially debugger friendly: Most people call the error_code constructors directly for both success and failure values. Breakpoints have to be set carefully to avoid stopping when success values are constructed.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">In fairness to std::error_code, it has some nice properties too:</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">1. It's extremely lightweight.</div><div style="font-size:13px" class="">2. It's explicit in the API (unlike exceptions).</div><div style="font-size:13px" class="">3. It doesn't require C++ RTTI (a requirement for use in LLVM).</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">To address these shortcomings I have prototyped a new error-handling scheme partially inspired by C++ exceptions. The aim was to preserve the performance and API visibility of std::error_code, while allowing users to define custom error classes and inheritance relationships 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.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">The scheme has three major "moving parts":</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">1. A new 'TypedError' class that can be used as a replacement for std::error_code. E.g.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">std::error_code foo();</font></div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">becomes</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">TypedError foo();</font></div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">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 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.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I really like the fact that not checking the error triggers an error (this is the "hard to misuse” part of API design IMO).</div><div class="">You don’t mention it, but I’d rather see this “checked” flag compiled out with NDEBUG.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">2. A utility class, TypedErrorInfo, for building error class hierarchies rooted at 'TypedErrorInfoBase' with custom RTTI. E.g.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">// Define a new error type implicitly inheriting from TypedErrorInfoBase.</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">class MyCustomError : public TypedErrorInfo<MyCustomError> {</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">public:</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""> // Custom error info.</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">};</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""><br class=""></font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">// Define a subclass of MyCustomError.</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">class MyCustomSubError : public TypedErrorInfo<MyCustomSubError, MyCustomError> {</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">public:</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""> // Extends MyCustomError, adds new members.</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">};</font></div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">3. A set of utility functions that use the custom RTTI system to inspect and handle typed errors. For example 'catchAllTypedErrors' and 'handleTypedError' cooperate to handle error instances in a type-safe way:</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">TypedError foo() {</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""> if (SomeFailureCondition)</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""> return make_typed_error<MyCustomError>();</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">}</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""><br class=""></font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">TypedError Err = foo();</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""><br class=""></font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">catchAllTypedErrors(std::move(Err),</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""> handleTypedError<MyCustomError>(</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""> [](std::unique_ptr<MyCustomError> E) {</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""> // Handle the error.</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""> return TypedError(); // <- Indicate success from handler.</font></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">What does success or failure means for the handler?</div><span class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-size:13px" class=""><font face="monospace, monospace" class=""> }</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""> )</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">);</font></div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">If your initial reaction is "Too much boilerplate!" I understand, but take comfort: (1) In the overwhelmingly common case of simply returning errors, the usage is identical to std::error_code:</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class=""><font face="monospace, monospace" class="">if (TypedError Err = foo())</font></div><div style="font-size:13px" class=""><font face="monospace, monospace" class=""> return Err;</font></div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">and (2) the boilerplate for catching errors is usually easily contained in a handful of utility functions, and tends not to crowd the rest of your source code. My initial experiments with this scheme involved updating many source lines, but did not add much code at all beyond the new error classes that were introduced.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">I believe that this scheme addresses many of the shortcomings of std::error_code while maintaining the strengths: </div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">1. Context - Custom error classes enable the user to attach as much contextual information as desired.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">2. Difficult to drop - The 'checked' flag in TypedError ensures that it can't be dropped, it must be explicitly "handled", even if that only involves catching the error and doing nothing.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">3. Debugger friendly - You can set a breakpoint on any custom error class's constructor to catch that error being created. Since the error class hierarchy is rooted you can break on TypedErrorInfoBase::TypedErrorInfoBase to catch any error being raised.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">4. Lightweight - Because TypedError instances are just a pointer and a checked-bit, move-constructing it is very cheap. We may also want to consider ignoring the 'checked' bit in release mode, at which point TypedError should be as cheap as std::error_code.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Oh here you mention compiling out the “checked” flag :)</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">5. Explicit - TypedError is represented explicitly in the APIs, the same as std::error_code.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">6. Does not require C++ RTTI - The custom RTTI system does not rely on any standard C++ RTTI features.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">This scheme also has one attribute that I haven't seen in previous error handling systems (though my experience in this area is limited): Errors are not copyable, due to ownership semantics of TypedError. I think this actually neatly captures the idea that there is a chain of responsibility for dealing with any given error. Responsibility may be transferred (e.g. by returning it to a caller), but it cannot be duplicated as it doesn't generally make sense for multiple people to report or attempt to recover from the same error.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">I've tested this prototype out by threading it through the object-creation APIs of libObject and using custom error classes to report errors in MachO headers. My initial experience is that this has enabled much richer error messages than are possible with std::error_code.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">To enable interaction with APIs that still use std::error_code I have added a custom ECError class that wraps a std::error_code, and can be converted back to a std::error_code using the typedErrorToErrorCode function. For now, all custom error code classes should (and do, in the prototype) derive from this utility class. In my experiments, this has made it easy to thread TypedError selectively through parts of the API. Eventually my hope is that TypedError could replace std::error_code for user-facing APIs, at which point custom errors would no longer need to derive from ECError, and ECError could be relegated to a utility for interacting with other codebases that still use std::error_code.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">So - I look forward to hearing your thoughts. :)</div></div></div></blockquote><br class=""></span><div class="">Is your call to catchAllTypedErrors(…) actually like a switch on the type of the error? What about a syntax that looks like a switch?</div><div class=""><br class=""></div><div class="">switchErr(std::move(Err))</div><div class=""> .case< MyCustomError>([] () { /* … */ })</div><div class=""> .case< MyOtherCustomError>([] () { /* … */ })</div><div class=""> .default([] () { /* … */ })</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi </div><br class=""><blockquote type="cite" class=""><div class=""><span class=""><div dir="ltr" class=""><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">Cheers,</div><div style="font-size:13px" class="">Lang.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class=""><div class="">Attached files:<br class=""></div><div class=""><br class=""></div><div class="">typed_error.patch - Adds include/llvm/Support/TypedError.h (also adds anchor() method to lib/Support/ErrorHandling.cpp).</div><div class=""><br class=""></div><div class="">error_demo.tgz - Stand-alone program demo'ing basic use of the TypedError API.</div></div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">libobject_typed_error_demo.patch - Threads TypedError through the binary-file creation methods (createBinary, createObjectFile, etc). Proof-of-concept for how TypedError can be integrated into an existing system.</div><div style="font-size:13px" class=""><br class=""></div></div>
</span><span class=""><typed_error.patch></span><span class=""><error_demo.tgz></span><span class=""><thread_typederror_through_object_creation.patch></span>_______________________________________________<span class=""><br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></span></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>