<div dir="ltr">Hello,<div>       I would just like to add one more point to this discussion about error strings being human readable or not, I guess the whole purpose</div><div>of having error strings, is to present them to human users right ? i mean a use case of sending strings, that are not human readable won't be</div><div>required.</div><div><br></div><div>So I can work on this point and upload a patch for review. I will add all people in this discussion in the review as well.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 27, 2017 at 11:27 AM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 26 June 2017 at 18:19, Chris Quenelle via lldb-dev<br>
<div><div class="h5"><<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> My main concern was that *if* strings are added, there's some<br>
> clear documentation about the relationship between the string<br>
> and the number to explain what's going on.  Based on other<br>
> emails in this thread it seems like the numbers are so unreliable that<br>
> it might not be worth the trouble.<br>
><br>
> What about this approach instead?<br>
><br>
> Define a new mode of operation called something like "extended error<br>
> response"<br>
> and invent some way for the client to 1) detect if it's supported in the<br>
> server and then<br>
> 2) to enable the mode in the server.<br>
><br>
> Then define a better error interface.  You'd want it to resemble the<br>
> existing one<br>
> to make it easy for clients to enable it without having to write a bunch of<br>
> new code.<br>
><br>
> If many things can go wrong in the server, then you might want to have some<br>
> arbitrary<br>
> lines of text that can be retrieved by the client, and which are defined as<br>
> "human readable only"  In other words, warn clients not to parse this<br>
> extended<br>
> "Error log" type of string stuff.   The client could dump that to the human<br>
> on request.<br>
><br>
> That would give a lot of flexibility for the server to spit ad-hoc strings<br>
> into the error buffer.<br>
<br>
</div></div>I think that pretty much sums up what we were talking about. The<br>
client would enable the packet via e.g. QEnableStringErrors packet<br>
(the servers already know to reply "unsupported packet" to any packets<br>
they don't understand). Then the server can send<br>
"Exx;some_error_string" (instead of the usual "Exx"). Later, when the<br>
client converts that into a Status object he will use that string to<br>
initialize the error string. If the error string is not present he<br>
will simply initialize the error string to "Error 47". All of this<br>
would be completely invisible to all but the lowest layers of the gdb<br>
protocol code.<br>
<span class=""><br>
><br>
> You could also define a strict set of numeric codes for things that are<br>
> supposed to<br>
> common and stable between server versions and implementations.  But that<br>
> would<br>
> still be within the "extended error response" mode.<br>
><br>
<br>
</span>Right I don't think we have a use case for these extended error codes,<br>
so I'd postpone that discussion until a need arises. (Mainly because<br>
maintaining a set of backward/forward compatible set of numeric error<br>
codes is a pain).<br>
</blockquote></div><br></div>