Question

I have a running dispute with a colleague. He’s written a program that I’m calling using a System.Diagnostics.Process object and invoking process.Start(). Under certain circumstances, though, he wants to throw an exception to crash his own process, and I’m supposed to catch his exception using process.StandardError and deal with it from there.

My gut reaction is that this is a very bad idea; terminating a process via an unhandled exception is something that the Windows OS itself sits up and takes notice of, doing stuff like popping up error message boxes, which is very much undesirable. I think he should rather terminate gracefully with some meaningful error code, and I can check the ExitCode of the process. But he says an integer is not sufficient; he wants to transmit the error message in a string.

Am I right in my objection to having him throw the exception, crashing his own app? Is there an easy way for him to pass me a string error message, without us having to define a special communication mechanism between our two apps? What else would you recommend?

Answer 1

An ExitCode definitely sounds like a much better idea. It is far more graceful, and can be handled by numerous (if not all) calling environments. An ExitCode is meant for exactly this purpose.

In response to his statement that an ExitCode is not sufficient: it isn’t meant to be. An ExitCode is supposed to be used in conjunction with a specification document that details each exception code – the cause, the fix etc. This spec sheet may exist as a soft copy, hard copy or simply in the developer’s mind.