gui: say why the wallet would not open, where the user can see it (#136)

Every fatal startup path wrote to stderr and to printf, and on Windows
neither reaches anybody. printf is remapped to OutputDebugStringF, so it
lands in debug.log inside the data directory. A -mwindows binary started
by double-clicking has no stderr at all, and AttachTerminal() cannot
help: it attaches to a parent console, which a double-clicked exe does
not have.

So Bitflash exited silently. Someone whose wallet.dat needs a newer
build -- exactly what the wallet format guard was added to tell them --
double-clicked and watched nothing happen. The guard was correct and
mute, which is the failure it was written to prevent.

Fatal startup errors now go through one reporter: debug.log as before,
stderr as before, and a message box when there is a person in front of
the screen. Applied to the three that mean "your data will not open":
the block index failing to load, the block index throwing, and
wallet.dat failing or throwing.

The box is deliberately not shown for a headless node. Those run under
scheduled tasks and services, where a modal dialog waits forever for a
click nobody is there to make -- a hung process instead of an exit code.
Headless keeps stderr and the log.

LoadWallet() now also reports why it refused, in a sentence, instead of
only logging it. The unsupported-format case is the one that has to be
understood by whoever reads it, and "LoadWallet failed" is not that.

Verified by breaking a throwaway wallet on purpose and starting both
ways. Headless: exit code 1, no dialog, no process left behind. Windowed
with no console: a box naming the file, the Berkeley DB error, the usual
cause, and where to look for more.

1 files changed, 14 insertions, 5 deletions

diff --git a/src/db.cpp b/src/db.cpp
index 9334249..c8642e9 100644
--- a/src/db.cpp
+++ b/src/db.cpp
@@ -48,6 +48,10 @@ private:
 
 static CCriticalSection cs_db;
 static bool fDbEnvInit = false;
+
+// Why LoadWallet() refused, in words meant for the person who has to act on it.
+// Empty unless the reason is one we can name.
+string strWalletLoadError;
 DbEnv dbenv(0u);
 static map<string, int> mapFileUseCount;
 
@@ -625,6 +629,7 @@ bool CWalletDB::LoadWallet(vector<unsigned char>& vchDefaultKeyRet)
     bool fHaveStoredMineMode = false;
     bool fHaveStoredHDCoinType = false;
     vchDefaultKeyRet.clear();
+    strWalletLoadError.clear();
 
     // Satoshi's "todo: shouldn't we catch exceptions" sat here since 2009, and
     // it was not a nicety. Nothing on this path caught anything, so a record
@@ -779,11 +784,15 @@ bool CWalletDB::LoadWallet(vector<unsigned char>& vchDefaultKeyRet)
                 ssValue >> nMinVersion;
                 if (nMinVersion > WALLET_FORMAT_SUPPORTED)
                 {
-                    printf("LoadWallet: wallet.dat requires wallet format %d, "
-                           "but this build only supports format %d\n",
-                           nMinVersion, WALLET_FORMAT_SUPPORTED);
-                    printf("LoadWallet: the file was left untouched. Upgrade "
-                           "Bitflash before opening this wallet.\n");
+                    // Said out loud, not only into debug.log: this is the one
+                    // refusal whose whole purpose is to be understood, and the
+                    // caller puts it in front of the user.
+                    strWalletLoadError = strprintf(
+                        "This wallet.dat was written by a newer version of Bitflash "
+                        "(wallet format %d; this build understands %d). Upgrade "
+                        "Bitflash before opening it.",
+                        nMinVersion, WALLET_FORMAT_SUPPORTED);
+                    printf("LoadWallet: %s\n", strWalletLoadError.c_str());
                     return false;
                 }
             }