API of CommandExecutor and its behaviour on non-zero exit codes

Andreas Pakulat apaku at gmx.de
Sat Sep 1 10:02:44 UTC 2012


I finally was annoyed by constantly popping up message boxes in the
custom buildsystem plugin when the build failed to look at what
changed recently to cause this. It turns out the culprit is
e8710e1e552499fd76dad7d35737993619d458bd, which changed
CommandExecutor to send our the procError signal also when a normal
execution exited with a non-zero exit code.

The problem with that is that this changes the meaning of the API.
procError was so far meant to indicate a problem with the process
itself, it wasn't meant as a way to indicate that the result of the
process is not 'successful'. So things like failure to start, crashes
and other unusual process-execution problems are to be tracked. In
particular they're often causing popups to be shown to make the user
aware of that.

IMHO if a process exits normally with a non-zero code, then the
command-execution was sucessfully done and hence there's no reason to
communicate an error to the caller from the API of CommandExecutor.

According to the commit the ninja-job execution didn't notice that
building wasn't successful. I don't know that codebase, but this
sounds like instead of relying on procError it should handle the
exit-code of the process in its completed slot instead. This is
currently not exposed, but we can easily add the exit-code to the
completed signal.

Thoughts? Opinions?


PS: I reverted the kdevplatform commit for now to make the existing
users of CommandExecutor less annoying again (for example running an
app which terminates with non-zero always yielded 2 messages boxes

More information about the KDevelop-devel mailing list