mat issueshttps://0xacab.org/mat/mat/-/issues2017-12-07T05:58:46Zhttps://0xacab.org/mat/mat/-/issues/11528Please communicate to the user any failure in the Nautilus extension2017-12-07T05:58:46ZintrigeriPlease communicate to the user any failure in the Nautilus extensionI did a blame-free post-mortem of https://bugs.debian.org/858058 (aka. #11527). It happened because of the combination of a number of small failures and missing pieces:
* lack of automated QA for this feature: requested autopkgtests in ...I did a blame-free post-mortem of https://bugs.debian.org/858058 (aka. #11527). It happened because of the combination of a number of small failures and missing pieces:
* lack of automated QA for this feature: requested autopkgtests in Debian on https://bugs.debian.org/858204, upstream tests would be welcome as well but that's not what this ticket is about
* lack of manual QA for this feature: I'll ignore this for now, hoping that automated QA is implemented soon enough; if this doesn't happen we should probably consider documenting a manual test suite in our release process doc
* developers not testing the code they just refactored: I don't think we can do much about this, except learning from this sad experience
* `menu_activate_cb` in `nautilus/nautilus-mat.py` being overly self-confident, and thus not robust enough in face of programming errors => silently failing
This ticket is about the last of these root causes: perhaps `menu_activate_cb` should wrap all its code in a try/catch block, and display an error dialog to the user if any unhandled exception is raised.
Thoughts?