This is the mail archive of the
mailing list for the GDB project.
Re: cleanup mi error message handling
> > My point is that since the code may be of value (the author has gone to
> > some trouble to create two error channels) and as it's not causing much
> > inconvenience it's best to leave things as they are for the moment. I
> > could give a long list of things that are more important to work on.
> If we want to distinguish them, the correct form is to encode it in the
> exception itself. We can add a new MI_GENERIC_ERROR to "enum errors",
> and come up with a new mi_error function that throws that error class
> instead of GENERIC_ERROR. Then we can catch those instead of
> handling MI_CMD_ERROR in a pass-error-code-in-return-of-function style.
I wanted to make less work, not more. I don't feel strongly enough about
the matter to try to justify it any further. I don't see that much is gained
but there probably isn't much lost either.