Which .NET exception should I use for signaling external application failure?

Question

I'm new to using C# and .NET, but I want to try to play nice and re-use system components.

In the code I'm maintaining, there are several instances where we run external tools and applications, which looks something like this:

using (var Setup = Process.Start(SetupInfo) )
{
    Setup.WaitForExit(SetupTimeout);
    if (!Setup.HasExited )
        throw new TimeoutException(
            "Setup did not complete within the expected time");
}

I'm trying to add validation of the exit codes as well for those external tools that have well-defined exit codes, i.e. something like this inside the 'using' block:

switch ( Setup.ExitCode )
{
    case 0: 
        break;
    case 1: 
        throw new SetupFailedException("Setup execution failed");
    case 2: 
        throw new SetupFileNotFound("Setup did not find required files");
    default: 
        throw new ExternalErrorException("Setup failed for some other reason");
}

...where the first two would derive from the generic 'ExternalErrorException'. But is there some existing generic exception I could re-use for this, i.e. to signal that an external process has failed to run as expected, rather than invent my own?

score 3 · Answer 1 · answered May 06 '11 at 13:23

3

Throwing a dedicated exception type only makes sense if there is code somewhere up the call stack that is going to catch the exception and deal with the failure. Dealing with a gross error like this is quite difficult, you have no idea why the setup program is misbehaving like this.

Which makes it very likely that there is little point in continuing to execute code, things just go downhill from there. After all, an essential program didn't get installed, it is quite liable to throw more exceptions when you try to use it. Now without a good explanation why it failed, the true reason was that the installer didn't work.

Or, if this is just an auxiliary operation that doesn't otherwise affect your main program, needs to be reported to the user so she can contact IT support to figure out a way around the problem.

Neither of which requires a dedicated set of exception types. Only catch exceptions that you know how to recover from.

answered May 06 '11 at 13:23

Hans Passant

922,412
146
1,693
2,536

Well, this is test code for a multi-tier system. If an installer fails, the test agent needs to at least report back to the controller which machine has failed and if possible why. This also means that in some cases these errors are actually recoverable from the test controller side by re-scheduling jobs. – Christoffer May 06 '11 at 18:51
That's what Exception.Message is for. I don't see how rescheduling a job solves a problem with a hung installer. It will most likely just hang again, over and over. – Hans Passant May 06 '11 at 20:21
...unless it fails because the file server it installs from is temporarily blocking requests because too many machines are hitting it at the same time, in which case an immediate re-scheduling is what we have found empirically to be the best solution – Christoffer Jun 06 '11 at 08:48

score 2 · Accepted Answer · answered May 06 '11 at 13:21

2

I don't think there is one you could reuse.

I think throwing your own exceptions has more value, it allows you to be specific. Your base exception usage is something I like to do too.

answered May 06 '11 at 13:21

I'll accept this answer because you answer the question rather than make assumptions about the context :-) – Christoffer May 13 '11 at 08:09

score 2 · Answer 3 · edited May 23 '17 at 12:19

As Hans mentioned, it doesn't make much sense here to create custom exception types for each case since the calling code is unlikely to act upon the different result cases. I would go even farther and avoid the use of even a single custom exception type if possible.

Personally, I would use System.Runtime.InteropServices.ExternalException for all cases, and simply add the failure reason (when available based on the exit code and/or other data) to the exception message. If you ever need to add subclasses for specific cases, these can derive from ExternalException instead of a custom type.

Why do you think the calling code is unlikely to handle such exceptions? — Christoffer, May 06 '11 at 19:01

score 1 · Answer 4 · edited May 23 '17 at 12:04

1

Why are you throwing exceptions? From what you are saying, it seems you have specific logic that needs to be performed based on the results of the setup. An Exception is not the way to signal business logic. If anything, I'd have an enumeration that corresponds to the exit codes which can then be checked.

If you really have a need to trash the stack and have an Exception bubble all the way up, you can have your method return a value from the enumeration, and then have a wrapper method which would take the value and then map to an Exception which should be thrown.

Ultimately, if you feel that using a custom Exception is the right way to go, then you should not have a deep Exception hierarchy. Rather, you would derive from Exception directly.

edited May 23 '17 at 12:04

Community

1
1

answered May 06 '11 at 13:16

casperOne

73,706
19
184
253

I really think it's fine to use exceptions here. Setup is not expected to fail. Don't really see how it's failure is part of business logic. Can the system recover or can the user intervene? – May 06 '11 at 13:26
@Tungano: Whether or not it's fine to use exceptions here is a question that only @Christoffer can answer; you and I don't know what this will be used to drive. However, it's clear that if this is business logic, then an `Exception` being used to *drive* that logic is considered a bad practice. – casperOne May 06 '11 at 13:50
Exceptions are used to signal error states. That is a design decision that I have no influence over. – Christoffer May 06 '11 at 18:55
@Christoffer: That sucks, unfortunately, as an error state that you can handle (vs an exceptional case, which is what an `Exception` is for) is always preferable. – casperOne May 06 '11 at 19:12
@casperOne well, not really. This is a distributed system that uses .NET remoting, so throwing exceptions is actually a relatively clean way to signal errors across machines. – Christoffer May 06 '11 at 19:15
@Christoffer: Remoting doesn't make it easier or harder. You can just as easily pass error structures across the machine boundary. – casperOne May 06 '11 at 19:36

score 0 · Answer 5 · answered May 06 '11 at 13:22

0

As someone else has already questioned your motives I shall not do so. I like you often feel compelled to reuse .NET exceptions as that is what feels the most OOP but that is sometimes an excuse because I might be being lazy.

There's a lot of people that would state that the more verbose your exception is then the better it may be for consuming applications/developers of your code especially if you comment your exception class fully.

answered May 06 '11 at 13:22

Paulie Waulie

1,690
13
23

Well, being lazy is not a bad thing in software development ;-) [And to avoid flames: I mean lazy as in doing less work, not procrastination] – Christoffer May 06 '11 at 18:59

Which .NET exception should I use for signaling external application failure?

5 Answers5