monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] "throw usage(); " or "N(); " for argument checking?


From: Zack Weinberg
Subject: Re: [Monotone-devel] "throw usage(); " or "N(); " for argument checking?
Date: Sun, 4 Jan 2009 11:14:56 -0800

On Sun, Jan 4, 2009 at 10:30 AM, Timothy Brownawell <address@hidden> wrote:
> On Sun, 2009-01-04 at 18:41 +0100, Markus Wanner wrote:
>> Timothy Brownawell wrote:
>> > "N(false, message)" results in "throw informative_faulure(message)", the
>> > question is what to throw rather than whether to throw.
>>
>> I'm with Timothy on that. These states are exceptional enough and much
>> simpler to code. While "control loops" (why a loop, simple conditions
>> would do, no?) clutter .. ehm.. exception handling a lot.

Yes, especially in the present state where command-line errors are
detected within the CMD() function, which is several levels down from
the code that generates the usage message.  It really is an
exceptional transfer of control.

>> > A command that does "throw usage()" gives the same result as calling
>> > "mtn help <command>", printing full usage info to stderr, where N()
>> > results in "mtn: misuse: <message>" on stderr and will put a note in any
>> > debug log.
>>
>> As long as the <message> is maintained in case of "throw usage()", I'm
>> fine. I dislike tools which just throw the complete usage page at me and
>> let me figure myself. Some hint on what's wrong certainly helps. And
>> that hint should survive, IMO.
>
> So I guess we should standardize on "throw usage()", but give usage a
> what() and make the constructor take a message.

I'm dubious about printing the full usage message on any command line
mistake.  Those are often long enough that they make the actual
diagnostic scroll off the top of the terminal or at least be visually
lost in a sea of chatter.

What would be really good is if we could give customized usage advice
based on the error, e.g. currently we have

$ mtn ls
mtn: misuse: no subcommand specified for 'ls'

but 'mtn help ls' prints a 55-line message the relevant part of which
is in the *middle.*  It would be great if we could extract just the
"subcommands of 'mtn ls'" part of that message and print it after the
above diagnostic.

zw




reply via email to

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