[lldb-dev] Support for Error Strings in remote protocol

[Pavel Labath via lldb-dev]

On 26 June 2017 at 18:19, Chris Quenelle via lldb-dev
<lldb-dev at lists.llvm.org> wrote:
>
> My main concern was that *if* strings are added, there's some
> clear documentation about the relationship between the string
> and the number to explain what's going on.  Based on other
> emails in this thread it seems like the numbers are so unreliable that
> it might not be worth the trouble.
>
> What about this approach instead?
>
> Define a new mode of operation called something like "extended error
> response"
> and invent some way for the client to 1) detect if it's supported in the
> server and then
> 2) to enable the mode in the server.
>
> Then define a better error interface.  You'd want it to resemble the
> existing one
> to make it easy for clients to enable it without having to write a bunch of
> new code.
>
> If many things can go wrong in the server, then you might want to have some
> arbitrary
> lines of text that can be retrieved by the client, and which are defined as
> "human readable only"  In other words, warn clients not to parse this
> extended
> "Error log" type of string stuff.   The client could dump that to the human
> on request.
>
> That would give a lot of flexibility for the server to spit ad-hoc strings
> into the error buffer.

I think that pretty much sums up what we were talking about. The
client would enable the packet via e.g. QEnableStringErrors packet
(the servers already know to reply "unsupported packet" to any packets
they don't understand). Then the server can send
"Exx;some_error_string" (instead of the usual "Exx"). Later, when the
client converts that into a Status object he will use that string to
initialize the error string. If the error string is not present he
will simply initialize the error string to "Error 47". All of this
would be completely invisible to all but the lowest layers of the gdb
protocol code.

>
> You could also define a strict set of numeric codes for things that are
> supposed to
> common and stable between server versions and implementations.  But that
> would
> still be within the "extended error response" mode.
>

Right I don't think we have a use case for these extended error codes,
so I'd postpone that discussion until a need arises. (Mainly because
maintaining a set of backward/forward compatible set of numeric error
codes is a pain).