[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Error handling via automate

From: Thomas Keller
Subject: Re: [Monotone-devel] Error handling via automate
Date: Mon, 11 Sep 2006 12:25:15 +0200
User-agent: Thunderbird 1.5 (X11/20060317)

Jon Bright schrieb:
> Nathaniel Smith wrote:
>> (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.)
> Speaking as someone who's writing something to use automate, I wouldn't
> have a problem with this strategy.  automate stdio optimises for
> repeated strings of commands.  Restarting the process isn't optimal, but
> it doesn't seem like it's a huge cost in the case of an error.

This, however, doesn't solve at all the problem how a client application
should be able to "weight" the fatalness of an error. If a user types in
a revision ID by hand into an input field to which he wants to update
(maybe he was pointed to it explicitely and doesn't use some nice
selector interface), it may be sufficient for automate update or
automate certs to tell the user f.e. "the revision is unknown" and not
to exit completly. A subsequent mtn pull might fix this little problem
already, so there is no need to exit from the process.

IMHO one should *only* exit from the main process if further commands of
the same and/or similar type will fail because of it as well, like "no
workspace found", "database needs to be migrated", "database locked" and
stuff like this. Most of those things already happen on stdio startup,
but not all (I'd need to dive into mtn's code to make you a complete
list, since I don't know exactly myself), like the previously stated
"database is locked" error states.


- "I know that I don't know." (Sokrates)
Guitone, a frontend for monotone:
Music lyrics and more:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]