From: Eric Wong <e@80x24.org>
To: Jeff King <peff@peff.net>
Cc: "Jonathan Nieder" <jrnieder@gmail.com>,
"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 07:42:51 +0000 [thread overview]
Message-ID: <20180228074251.GA11673@dcvr> (raw)
In-Reply-To: <20180228050034.GA373@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Wed, Feb 28, 2018 at 04:07:18AM +0000, Eric Wong wrote:
>
> > > 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.
<snip>
> > > d) We could wrap each command in an eval {...} block to convert the
> > > result from die() to exit 128.
> >
> > I prefer option d)
>
> FWIW, I agree with all of that. You can do (d) without an enclosing eval
> block by just hooking the __DIE__ handler, like:
>
> $SIG{__DIE__} = sub {
> print STDERR "fatal: @_\n";
> exit 128;
> };
Looks like it has the same problems I pointed out with a) and b).
next prev parent reply other threads:[~2018-02-28 7:42 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
2018-02-28 5:00 ` Jeff King
2018-02-28 7:42 ` Eric Wong [this message]
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=20180228074251.GA11673@dcvr \
--to=e@80x24.org \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=jojo@schmitz-digital.de \
--cc=jrnieder@gmail.com \
--cc=peff@peff.net \
--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.