Hello,
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
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
required.
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.
On Tue, Jun 27, 2017 at 11:27 AM, Pavel Labath <lab...@google.com> wrote:
> On 26 June 2017 at 18:19, Chris Quenelle via lldb-dev
> <lldb-dev@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).
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
