<div dir="ltr">The problem is not returning an error from Minidump::Create() - if that was the case this could easily be improved indeed. The two-phase initialization is a consequence of the LLDB plugin lookup:<div><br></div><div>1. <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Target::CreateProcess() calls <span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Process::FindPlugin()</span></span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"></span>2. ProcessMinidump::CreateInstance() then has to inspect the core file to see if it's a minidump</div><div>2b. ... if it is a minidump, we need to create a ProcessMinidump (which calls <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">MinidumpParser::Create())</span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">3. once the plugin is selected, Process::LoadCore() is finally called and this the earliest we can do minidump-specific error checking</span></div><div><br></div><div>Note that at step 2b. we don't have a way to propagate the error since we're just doing the plugin lookup (the most we can pass on the lookup to the rest of the plugins). We can't easily defer the MinidumpParser::Create() as step 2b either since that only morphs into a different kind of two-stage initialization (having a ProcessMinidump w/o a parser).</div><div><br></div><div>I agree that it would be nicer with a one step initialization but overall changing the LLDB plugin lookup is too intrusive for the relatively small benefit. If you have any suggestions I'd love to hear them.</div><div><div><div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 16, 2018 at 9:04 AM, Pavel Labath via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">labath added a comment.<br>
<br>
I don't agree with the two-stage initialization of the MinidumpParser class being introduced here. We deliberately introduced the `Create` static function to avoid this. If this `Initialize` function in checking invariants which are assumed to be hold by other parser methods, then it should be done by the `Create` function. Ideally this would be done before even constructing the parser object, but if this is impractical for some reason then you can make the `Initialize` function private and call it directly from `Create`. This way a user will never be able to see an malformed parser object. To make sure you propagate the error, you can change the return type of `Create` to `llvm::Expected<<wbr>MinidumpParser` (the only reason we did not do this back then was that there was no precedent for using `Expected` in LLDB, but this is no longer the case).<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D49202" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D49202</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>