<div dir="ltr"><br><div>My main concern was that *if* strings are added, there's some </div><div>clear documentation about the relationship between the string</div><div>and the number to explain what's going on. Based on other</div><div>emails in this thread it seems like the numbers are so unreliable that</div><div>it might not be worth the trouble.</div><div><br></div><div>What about this approach instead?</div><div><br></div><div>Define a new mode of operation called something like "extended error response"</div><div>and invent some way for the client to 1) detect if it's supported in the server and then</div><div>2) to enable the mode in the server.</div><div><br></div><div>Then define a better error interface. You'd want it to resemble the existing one</div><div>to make it easy for clients to enable it without having to write a bunch of new code.</div><div><br></div><div>If many things can go wrong in the server, then you might want to have some arbitrary</div><div>lines of text that can be retrieved by the client, and which are defined as </div><div>"human readable only" In other words, warn clients not to parse this extended</div><div>"Error log" type of string stuff. The client could dump that to the human on request.</div><div><br></div><div>That would give a lot of flexibility for the server to spit ad-hoc strings into the error buffer.</div><div><br></div><div>You could also define a strict set of numeric codes for things that are supposed to </div><div>common and stable between server versions and implementations. But that would</div><div>still be within the "extended error response" mode.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 26, 2017 at 7:29 AM, Ravitheja Addepally <span dir="ltr"><<a href="mailto:ravithejawork@gmail.com" target="_blank">ravithejawork@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div> From my understanding (please correct me if i am wrong) , currently the error codes returned by lldb-server are completely arbitrary.</div><div>Now the SBError class in the public API interface of lldb does contain a string. I think in erroneous cases, lldb seems to set the String</div><div>in the lldb Status class more often than the error code. I seriously doubt if there is a coherent structure in the error classes.</div><div><br></div><div>This whole error structure is borrowed from GDB, which is vague about error codes. Now there are two questions we need to answer -></div><div>1) Do we want to have ability to send error strings in the error packets ?</div><div>2) If Yes then how ?</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 23, 2017 at 1:01 AM, Chris Quenelle <span dir="ltr"><<a href="mailto:cq7840@gmail.com" target="_blank">cq7840@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I’m just a new lurker here, so maybe this is obvious…<br>
<br>
Is the string part of the programmatic interface? Or just a comment?<br>
Does the same numeric code always have the same string?<br>
If the same numeric code can have different strings, then the string<br>
represents a specialization of the error code? If clients depend on<br>
the data that’s in the string, then they may not work correctly in<br>
modes of operation where the string is not available from the server.<br>
<br>
If it’s intended to be part of the API then maybe a structured name/value<br>
approach might be better?<br>
<br>
Or maybe it’s just supposed to be a form self-documentation so that inspection<br>
of the raw error codes is easier to diagnose? In that case maybe the string<br>
is always 1-to-1 with the error code?<br>
<div class="m_2643015019633464885HOEnZb"><div class="m_2643015019633464885h5"><br>
> On Jun 21, 2017, at 8:31 AM, Ravitheja Addepally via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hello all,<br>
> Currently the remote protocol in LLDB does not allow sending Error Strings in response to remote packets, it only allows for "ENN" format where N is a hex integer. In our current ongoing work, we would like to have support for Sending Error Strings from lldb-server. I would like to invite any opinions or suggestions in this matter ?<br>
><br>
> A very simple proposal would be to just attach an error string maybe as a Name:Value Pair ? like so -><br>
><br>
> EXX;"Error String"<br>
> or<br>
> EXX;M"Error String"<br>
><br>
> I guess removing EXX would make it incompatible with gdb-server. Also adding new packets to query errors might not be desired ?<br>
><br>
><br>
> Regards,<br>
> A Ravi Theja<br>
><br>
><br>
</div></div><div class="m_2643015019633464885HOEnZb"><div class="m_2643015019633464885h5">> ______________________________<wbr>_________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br>
<br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div>