#9 exception in output method causes strange behavior

[Eric Huss]

If you use the IOutputConsumer interface, and one of your methods (such as outputRecord) raises an exception, the default Perforce method gets called (printing everything to stdout) before the exception is handled. This is confusing, especially if your command outputs a large amount of data.

I tried to track down the problem, but I couldn't figure out why it was behaving that way. For some reason, inside OutputStat, the p4api_ClientUser_isMethodOverridden is returning false, which calls the Perforce default ClientUser::OutputStat, whose default behavior is to print the output.

Attached is a little sample program.

[Eric Huss]

sample program

[Lewis Baker]

Logged In: YES
user_id=1477305
Originator: NO

I've had a look at the code and it seems that many of the calls into Python ClientUser methods don't actually catch the exceptions and clear the exception state. This could be causing downstream Python API calls that check for an exception state to fail (perhaps causing isMethodOverridden to return false on a subsequent callback).

The obvious solution to this is to catch and clear any exceptions thrown by overridden ClientUser methods called from run().

I toyed around a while ago with recording exceptions thrown in ClientUser methods and re-raising them from the call to ClientApi.run(). However, I couldn't come up with a consistent model for handling multiple exceptions being raised. Should a thrown exception cause a KeepAlive callback to abort the command? If multiple exceptions are raised should the first or last exception be re-raised from ClientApi.run()? In the end I thought it better to let the ClientUser catch the exception themselves if they want to handle it later.