Re: cleanup mi error message handling

[Nick Roberts <nickrob at snap dot net dot nz>]

 > > 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.

-- 
Nick                                           http://www.inet.net.nz/~nickrob