View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0004470Slicer4Core: Scripting (Wrapping, Python)public2017-10-30 15:392018-06-01 09:44
Reporterinorton Assigned Toinorton  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionnot fixable 
Product Version 
Target VersionFixed in Version 
Summary0004470: Python slicer.util.exit is asynchronous?
Description

Calling slicer.util.exit multiple times within a Python invocation/script leads to surprising results: only the last call exit status is counted. This can be unhelpful when writing a Python test script that returns status via exit code.

Steps To Reproduce

On unixy system:

/path/to/Slicer/Slicer --python-code "slicer.util.exit(1); slicer.util.exit(0)"
echo $?

TagsNo tags attached.

Activities

jcfr

jcfr

2017-10-30 15:46

administrator   ~0015366

Good catch.

This function calls http://doc.qt.io/qt-4.8/qcoreapplication.html#exit

This means we should stop interpreting python code after the user expect the application to exit/quit.

Is it something you could look into ?
inorton

inorton

2017-10-30 16:14

developer   ~0015367

For now I'm just using sys.exit directly from Python. This kills the application and gives the expected result. I can take a look at some point, although from the link the issue may be upstream. I confirmed the behavior is identical in Qt5.
lassoan

lassoan

2018-05-30 14:27

developer   ~0015855

sys.exit should be avoided as it does not let the software to properly close resources, clean up state before exit. etc..

The current behavior is that the error code that was most recently set using slicer.util.exit() will be returned. I think this is a good choice and maybe it could be surprising for command-line tool developers but is expected for application developers.

What do you think about resolving this issue by improving documentation? See this pull request: https://github.com/Slicer/Slicer/pull/964

Issue History

Date Modified Username Field Change
2017-10-30 15:39 inorton New Issue
2017-10-30 15:39 inorton Status new => assigned
2017-10-30 15:39 inorton Assigned To => jcfr
2017-10-30 15:46 jcfr Note Added: 0015366
2017-10-30 16:14 inorton Note Added: 0015367
2017-10-30 16:14 inorton Assigned To jcfr => inorton
2018-05-30 14:27 lassoan Note Added: 0015855
2018-06-01 09:44 inorton Status assigned => closed
2018-06-01 09:44 inorton Resolution open => not fixable