All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Wong <e@80x24.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: "Randall S. Becker" <rsbecker@nexbridge.com>,
	git@vger.kernel.org,
	"'Joachim Schmitz'" <jojo@schmitz-digital.de>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.
Date: Wed, 28 Feb 2018 04:07:18 +0000	[thread overview]
Message-ID: <20180228040718.GA9043@whir> (raw)
In-Reply-To: <20180228001616.GJ174036@aiede.svl.corp.google.com>

Jonathan Nieder <jrnieder@gmail.com> wrote:
> The fundamental thing is the actual Git commands, not the tests in the
> testsuite, no?

Right.  I've never been picky about exit codes; only that a
non-zero happens on errors.

> In the rest of git, die() makes a command exit with status 128.  The
> trouble here is that our code in Perl is assuming the same meaning for
> die() but using perl's die builtin instead.  That suggests a few
> options:
> 
>  a) We could override the meaning of die() in Git.pm.  This feels
>     ugly but if it works, it would be a very small patch.

Unlikely to work since I think we use eval {} to trap exceptions
from die.

>  b) We could forbid use of die() and use some git_die() instead (but
>     with a better name) for our own error handling.

Call sites may be dual-use: "die" can either be caught by an
eval or used to show an error message to the user.

>  c) We could have a special different exit code convention for
>     commands written in Perl.  And then change expectations whenever a
>     command is rewritten in C.  As you might expect, I don't like this
>     option.

I don't like it, either.

>  d) We could wrap each command in an eval {...} block to convert the
>     result from die() to exit 128.

I prefer option d)

  reply	other threads:[~2018-02-28  4:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-27 23:50 [Problem] test_must_fail makes possibly questionable assumptions about exit_code Randall S. Becker
2018-02-28  0:16 ` Jonathan Nieder
2018-02-28  4:07   ` Eric Wong [this message]
2018-02-28  5:00     ` Jeff King
2018-02-28  7:42       ` Eric Wong
2018-02-28  7:49         ` Jeff King
2018-02-28 14:55           ` Randall S. Becker
2018-02-28 16:51             ` demerphq
2018-03-01  7:36               ` Jeff King
2018-03-01  8:16                 ` demerphq
2018-03-01 14:28                 ` Randall S. Becker
2018-03-01 15:08                   ` Jeff King
2018-03-01 15:30                     ` demerphq
2018-02-28 16:22           ` Junio C Hamano
2018-02-28 16:46           ` demerphq
2018-02-28 17:10             ` Randall S. Becker
2018-02-28 17:19               ` demerphq
2018-02-28 17:20                 ` demerphq
2018-02-28 17:32                 ` Randall S. Becker
2018-02-28 17:44               ` Jonathan Nieder
2018-02-28 18:21                 ` Randall S. Becker
2018-02-28 18:51                   ` Jonathan Nieder
2018-02-28 20:04                     ` Randall S. Becker
2018-02-28 22:02                       ` Randall S. Becker
2018-02-28 23:16                         ` Jonathan Nieder
2018-03-01  7:34             ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180228040718.GA9043@whir \
    --to=e@80x24.org \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jojo@schmitz-digital.de \
    --cc=jrnieder@gmail.com \
    --cc=rsbecker@nexbridge.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.