[Monotone-devel] Error handling via automate

[Thomas Keller]

Hi all!

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

Currently stdio only allows to distinguish three states:

0: no error
1: a syntax error popped up
2: any other error popped up

Error no. 1 doesn't pop up at all if my interface properly feeds the
needed command name and arguments into stdio (and this practically
always happens since all commands I use are predefined), so basically
stdio can only tell me "there was an error" or "there was no error".

Now comes the hard part: If there was an error, this error is obviously
printed out via stdio as well, and, this error is of course translated
and targeted to the end user, but not to my interface / program.
However, I need to distinguish certain errors from others which come
from there and base my further actions on the *type* of the error which
popped up (let us call them "fatal" and "nonfatal" errors).

To give you an example what I mean, consider the following error printed
out via stdio:

error: sqlite error: database is locked
-> another mtn process needs exclusive write access to a certain db,
   therefor no other actions are possible with this db until the write
   lock is released
-> if my GUI loads a new workspace, it triggers automate inventory to
   build the tree of files and its states. this fails with a locked db
   and is a fatal error for any further workspace actions since if I
   cannot build a tree, I have no UI to display to the user

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.

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.

Suggestions?

Thomas.

[0] Of course one has to cross the fingers that these strings do not
change too often (i.e. wording) as it would break the interface...

-- 
- "I know that I don't know." (Sokrates)
Guitone, a frontend for monotone: http://guitone.berlios.de
Music lyrics and more: http://musicmademe.com