Smart server transmits MemoryError as ('error', '')

[Andrew Bennetts]

This is related to some existing bugs, but I think it's a new bug.

When the smart server encounters an unexpected exception it catches it and sends a generic error back to the client of ('error', str(exception)). Unfortunately some errors, like MemoryError, have empty str()s. Our users would be much better served in this case if they knew it was a MemoryError; they may be able to self-diagnose and fix/workaround the cause of the problem, and when they can't they'll at least be able to file more informative bug reports.

I think we should:

 1. specially handle MemoryError: it's the most common case of these (we suspect). Either a new error code or a hard-coded generic error of ('error', 'memory error') would do.
 2. do better in the general case of exceptions with empty str()s. Perhaps detect that case and emit the repr() or exception class name instead? Perhaps always send the exception class name along with the str()?
 3. make it clear to the user of the client that it is (probably) a fault in the server, rather than the client (although some bugs are triggered by the user/client doing unusual or nonsensical actions...)

This bug is primarily about the first point. but perhaps the other points can be cheaply addressed at the same time.

[Martin Pool (mbp)]

In the specific case of Launchpad, see also bug 613806.

[Vincent Ladeuil (vila)]

+1 for 2: always send the exception class name along with the str()

+1 for 3 make it clear to the user of the client that it is (probably) a fault in the server

[Martin Packman (gz)]

I'll take this if you're not already working on it Andrew.

[Andrew Bennetts (spiv)]

> I'll take this if you're not already working on it Andrew.

Be my guest! :)

[Martin Packman (gz)]

First point in bug is addressed by linked branch, and continuation in <lp:~gz/bzr/smarter_smart_error_reporting_full_722416> which was merged at the same time covers points two and three.