Re: [Monotone-devel] Error handling via automate

[Nathaniel Smith]

On Fri, Sep 08, 2006 at 04:27:30PM +0200, Thomas Keller wrote:
> I'm currently struggle how to accomplish proper error handling for
> errors which are spit out by monotone's automate commands (and
> specifically mtn automate stdio).
[...]

Indeed -- thanks for the good summary of the issues.  Error handling
is a huge issue for automate, because all of monotone is written with
the assumption that as soon as anything goes at all wrong, we kill the
whole program.  Therefore, there is no thought put into whether an
error can ever leave us in an dangerous state, and no serious testing
of any error unwind logic.  In general we probably are pretty clean,
but it only takes one nasty bug to corrupt data...

(In fact 'automate stdio' makes me quite nervous for this reason
already.  I would feel better if part of its contract was that it
would exit after an error, and it was the client's responsibility to
restart it.)

So one of the parts of extending automate (possibly the single biggest
part) will be coming up with sensible error handling strategies, and
making the core code play more nicely with it.

> Now consider that we get mtn automate update implemented some time in
> the future, and think about the fact that one cannot update to the
> newest revision automagically as long as there are multiple heads
> floating around. I assume the error which such a mtn automate update
> would give me will be pretty similar to the one the current mtn update
> would spit out. And there is the problem: If one cannot update because
> of multiple heads, this is a nonfatal error, since the user could get
> the choice of selecting the appropriate revision he'd like to update to.
> This error needs to be handled differently from a fatal error, as other
> operations on the currently viewed workspace (like add, drop, commit)
> aren't affected at all by the fact that there are multiple heads.

Another possibility in this particular case would be "automate update"
simply require that the caller provide the target revision; then this
error can't happen.  Instead, the caller would go to get the target
for the update, discover there were multiple candidates, and then ask
the user (or whatever) before calling update at all.

> Now I don't say "distinguish between fatal and nonfatal errors", but I'd
> like to have a more general distinction of all errors than the native
> languaged based errors which are currently used.
> 
> This distinction could be a globally defined error code, an error string
> or alike and would be either spit out directly if something goes wrong,
> or could be asked for by some get_error automate command (or vice versa).
> 
> There are not many alternatives to this other than starting the stdio
> pipe with LC_MESSAGES=C and parse the original english strings[0], but
> this would affect all error strings and for some, like the above
> mentioned "database error" I'd surely like to have the proper (German)
> translation. I'd throw such an error to the user as its only him who can
> resolve it and in this case a native error would be far better than an
> English one.

Right -- parsing is terrible, no-one should ever have to do that.  You
probably want both some sort of machine readable thing (i.e., a
number or short string, which is documented and part of the
interface), plus a human-readable message, so clients can pick which
they want to use on a case-by-case basis.

Possibly the structure of SMTP/HTTP/FTP/... style response codes are a
useful precedent?  Or possibly there should be a small set of errors
defined on a per-command basis?

-- Nathaniel

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein