qml: pyqtSlots which return a result are returning garbage when an exception occurs, resulting in unpredictable behavior

[SomberNight]

Before commit f5f177f (so e.g. on the 4.4.0 tag), restoring from an old mpk (e.g. e9d4b7866dd1e91c862aebf62a49548c7dbf7bcc6e4b7b8c9da820c7737968df9c09d5a3e271dc814a29981f81b3faaf2737b551ef5dcc6189cf0f8252c442b3) in the qml wizard fails in a weird way:
QEBitcoin.verifyMasterKey() raises but the Next button becomes enabled and the user can proceed (though there is another not relevant failure later in the wizard).

Please test on master with the patch below.
Enter an xpub in the wizard, observe that QEBitcoin.verifyMasterKey() raises but in qml, this branch is not entered or there is no exception either, instead execution continues:

electrum/electrum/gui/qml/components/wizard/WCHaveMasterKey.qml

Lines 37 to 39 in f5f177f

	if (!bitcoin.verifyMasterKey(key, wizard_data['wallet_type'])) {
	validationtext.text = qsTr('Error: invalid master key')
	return false

So I guess the pyqtSlot is turning the exception into True??

electrum/electrum/gui/qml/qebitcoin.py

Lines 108 to 109 in f5f177f

	@pyqtSlot(str, str, result=bool)
	def verifyMasterKey(self, key, wallet_type='standard'):

diff --git a/electrum/gui/qml/components/wizard/WCHaveMasterKey.qml b/electrum/gui/qml/components/wizard/WCHaveMasterKey.qml
index 0a1ab37345..59f88b98ea 100644
--- a/electrum/gui/qml/components/wizard/WCHaveMasterKey.qml
+++ b/electrum/gui/qml/components/wizard/WCHaveMasterKey.qml
@@ -47,6 +47,7 @@ WizardComponent {
             }
         }
 
+        console.log('>>>>>>>>>>>>>>>>>>>>> verifyMasterKey setting valid=true <<<<<<<<<<<')
         return valid = true
     }
 
diff --git a/electrum/gui/qml/qebitcoin.py b/electrum/gui/qml/qebitcoin.py
index 274f9cd81b..6e6c8f5a02 100644
--- a/electrum/gui/qml/qebitcoin.py
+++ b/electrum/gui/qml/qebitcoin.py
@@ -113,6 +113,8 @@ class QEBitcoin(QObject):
             self.validationMessage = _('Not a master key')
             return False
 
+        raise Exception("blabla")
+
         k = keystore.from_master_key(key)
         if isinstance(k, keystore.Xpub):  # has xpub  # TODO are these checks useful?
             t1 = xpub_type(k.xpub)

@accumulator please have a look

[accumulator]

Hmm can't reproduce, with the patch above I'm getting a proper exception screen and no enabling of the Next button

[SomberNight]

Hmm, weird.
I apply the patch on master, run the qml gui, go into the wizard, start creating a wallet, then

• paste an xpub into the wizard
• the crash reporter dialog opens, I click "not now"
• then "next" is enabled, and I can click it to continue to the next screen

I was testing on desktop linux -- but have now tried on android and can reproduce there as well.

[accumulator]

Now I can reproduce.. weird. It's almost as if the exception case returns a random memory location as the result (?)

I couldn't find anything in the PyQt docs describing this scenario, so I'm afraid we just have to try/except any pyqtSlot which has a result value :(

[SomberNight]

removed from 4.4.2; we don't have to fix this now. but it is extremely weird and somewhat worrying

[accumulator]

It is weird, but at least the exception handler kicks in. Most applications terminate in such cases, but we are keeping the UI running as if nothing happened. Maybe we are too lenient there and we should terminate wallets and reset the UI in order to guard against undefined behavior after an uncaught exception.

[accumulator]

avoid the exception entirely 397019f

[SomberNight]

well... I mean... 397019f is a workaround for the concrete example explained here, but I think there is a general issue re exception handling that might manifest itself in other places. We should keep this open and have a look when we have more time.