Related – perhaps it should have been a separate issue, but here goes:

I'd like to be able to re-throw an exception after capturing it, either via the ?(…) construct or the except block of a try statement.

Suggestion:

• If $e is a caught exception, fail $e should re-throw it.
• however, fail $ok should do nothing at all, both in order to save the user a conditional and in order to avoid dealing with the dreaded “no error” error.

A comprehensive design is not there yet, but at least it should also be possible to access the message inside an exception raised by fail (see #986).

Exposing the traceback is a bit hairy, so for the sake of this issue I'll focus on just the cause. Exposing the traceback is tracked in #1042.

Design notes:

• Add predicates in the exc: for determining the type of the cause, e.g. exc:is-external-cmd-exit (may want to rename this; it's too long). Internal structured errors such as errs.OutOfRange can have similar predicates.

• Add fields for the data contained in the exception, e.g. $e[exit-code] for the numerical exit code (only present if exc:is-external-cmd-exit $e is true).

There is an open question regarding how to expose the many methods of Go's WaitStatus. There are several options:

• Expose them as fields of the exception too.

• Expose them as functions.

• Expose them as methods; Elvish doesn't have the concept of methods today, so this will be blocked on Elvish having methods in the first place.

I think exc:is-exit-code will work. Only external commands produce exit codes anyway; there is no need to spell it out. Also exc:is-signal. For the latter, it would be good to get both the signal number and the name.

After researching a bit more on how to name this: "exit" and "exit code" actually have narrower meanings than I thought (at least on the POSIX C API level). A process exits only when it terminates on its own. If it was killed by a signal, it never exited, and there is no exit code, only a signal number.

POSIX uses 128+N to signal a command was killed by a signal; Elvish could distinguish the two different cases by giving them different predicates (that seems to be what @hanche is suggesting). I'd pick different names though; exit-code and signal are not really exceptional conditions themselves; I'd use exc:is-nonzero-exit and exc:is-killed.

POSIX uses 128+N to signal a command was killed by a signal;

Note that is a POSIX shell (mis)feature. It is not a feature of the underlying kernel API. In UNIX the exit status is in the range [0, 255]. Exiting due to a signal is encoded in a fashion that ensures there is no ambiguity between SIGHUP (signal #1) and the program calling exit(129). Specifically, the exit code (if any) is left shifted eight bits by the kernel and or'ed with status bits and the terminating signal number (if any) in the low eight bits. This is an area where elvish can do better than the POSIX shell standard.

man 2 wait to see what that looks like in C. I haven't quite learned my way around the go documentation yet; searching for wait just seems to give me bits of source code, which is fine if you enjoy the Obi-Wan Stallman method of documentation (“use the Source, Luke!”).

Also, see this statement from https://en.wikipedia.org/wiki/Exit_status:

For the shell’s purposes, a command which exits with a zero exit status has succeeded. A nonzero exit status indicates failure. This seemingly counter-intuitive scheme is used so there is one well-defined way to indicate success and a variety of ways to indicate various failure modes. When a command is terminated by a signal whose number is N, a shell sets the variable $? to a value greater than 128. Most shells use 128+N, while ksh93 uses 256+N.

The POSIX 1003.2 shell standard more or less says the same thing. However, both documents are ambiguous. I find this situation particularly hilarious given how many fans of the ksh shell assert that it is 100% POSIX compliant. Ksh complies with the POSIX convention regarding the special exit statuses "126" and "127" but not the POSIX mandate to confuse an exit status in the range [128..255] with a termination due to a signal. At least with respect to the magic $? shell variable.

The bottom line is that it is impossible for Elvish to do the right thing, all of the time, with respect to exit statuses. One option is to follow the path I established for the Meson build system. See mesonbuild/meson@5290f41. However, I recommend that Elvish not attempt to handle shells that munge the exit status of the last external command they run. Just map the native API to an Elvish exception object. Don't attempt to divine (i.e., discover by guesswork)

a) if the external command really exited due to a signal as reported by the OS, or

b) exited by a signal because the external command was a shell that munged the exit status of the external command it ran.

It would be good sometimes to be able to query the exit code of the last command executed, without the need to capture an exception for it. My specific current use case is the implementation of iTerm2's Shell Integration features for Elvish, which among other things allow displaying a prompt marker which can indicate via its color the status of the last command. My current implementation is at https://github.com/zzamboni/elvish-modules/blob/master/iterm2.org, which works, but the marker is always displayed with the same color because there is no way to obtain this information.

I'm sure other use cases can be identified. Maybe something like $edit:last-command-status could be useful?

@zzamboni for that use case, I'd introduce an API for a default exception handler that is run interactively.

@zzamboni That is now #1059.