[Monotone-devel] On E()s and N()s

[Thomas Keller]

Hi all!

Our HACKING file explains two of the most used macros in monotone like this:

      N(x != y, F("make x and y equal")): "naughty" -- the user
         requested something that doesn't make sense, they should fix
         that.
      E(x != y, F("x and y are not equal")): "error" -- not a bug in
         monotone, not necessarily the users fault... dunno boss, it
         just isn't working!

On the user's side, both throw a fatal error "informative_failure" and
the only distinction we have internally after either macro's code was
executed is if we look at the error string afterwards: If we find
"misuse" prefixed, it was a naughty one, otherwise it was a "normal" error.

So why is this a problem, or at least, why is this ugly? Because a
clearer distinction between input errors ("the user did something wrong
(tm) - he should try it again with correct input") and processing errors
("something went wrong - its not clear if a retry with different input
will fix the issue") would be very helpful for the automation interface.

Simplest / best example is `automate select` here, when run over stdio:
If the user enters some wrong date format or other selector syntax, a
naughty error is (correctly) displayed. But what if the database is just
locked? We, again correctly, receive a general error about that. Both
errors are examined by automate stdio and since both are the same
exception, both set the errcode field in the stdio stream to "2",
forcing the interface implementor to check the prefix of the error string...

So what I'd propose here is that actually distinguish between these two,
and this could be as easy as creating a new naughty_failure class which
extends from informative_failure and throw an instance of this instead
the former in sanity.cc's sanity::naughty_failure. I'd also change the
what() getter to add the "misuse: " part of the naugthy failure on call
time and allow the return of the raw error without that prefix. Now the
rest of the code should just continue to work because
informative_failures are already catched and handled everywhere, and the
naughty_failure exception could (especially) be catched for automate
stdio and lead to a new error number within the stream context there.

What do you think?

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature