tox: Display exit code with InvocationErrors

When a command fails, you currently only get ERROR: InvocationError: '/usr/bin/false', but the exitcode itself is useful/important, e.g. with py.test using 5 for “no tests collected”.

The following patch would provide that, by using a custom __str__ method for InvocationError - but it does not handle the case where that might be missing (not all instances / calls to it provide it).

Maybe a custom __init__ should be used to set the arguments as properties explicitly, and then use them?!

diff -r e9569646da4f tox/__init__.py
--- a/tox/__init__.py   Wed Nov 25 12:27:48 2015 +0100
+++ b/tox/__init__.py   Wed Nov 25 13:23:26 2015 +0100
@@ -17,6 +17,9 @@
         "signals that an interpreter could not be found"
     class InvocationError(Error):
         """ an error while invoking a script. """
+        def __str__(self):
+            return "%s: %s (exitcode %d)" % (self.__class__.__name__,
+                                             self.args[0], self.args[1])
     class MissingFile(Error):
         """ an error while invoking a script. """
     class MissingDirectory(Error):

This is related / similar to #192.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 20 (6 by maintainers)

Commits related to this issue

Most upvoted comments

When a program crashes rather than exits (e.g. because of a segfault), it only "kinda’ has an exit code: It exits with 128 + number of the signal. That is, at least on Unix, not sure how things look on Windows.

It depends on how tox handles this in all places it raises an InvocationError. Here’s how things would look ideally, IMHO:

  • If it exited with != 0, tox would show “InvocationError: (command) exited with status 1” or so (being a bit more verbose doesn’t hurt here - I had dozens of people being confused about what InvocationError means and thought it was tox failing).
  • If it crashed, tox would show: “InvocationError: (command) crashed with SIGSEGV” or so.

That’d make things much clearer. I’m not sure how much effort it’d be though.

Understood now; “Crashed” was not appropriate, I was referring to https://github.com/pytest-dev/pytest-qt/issues/170#issuecomment-301019150, which was not a segmentation fault, but rather Qt aborting. In such a case there is no output at all (the tox process itself is killed, IIUC), and a documentation would not hurt.

Thank you both for your inputs, enough to get started.

@The-Compiler Agreed, being more verbose is better here. Intuitively, checking for os.getpid() in this exception would be too naive, and a quick grep on pid yields nothing. So what about supplementing the error message when exitcode > 128, with something like “On unix systems, an exit code larger than 128 often means a crash (e.g. segmentation fault)” ? (this should be better than a crash message for applications issuing large custom error codes)