Ideal way of handling exceptions and purposely failing execution of C# console application

Question

2.00/5 (1 vote)

See more:

I have created a console application to do some tasks that is to be called from an SSIS package. In the package I use an Execute Process Task to call the .exe and send arguments. It works fine.

The problem is that I'm handling exceptions in try/catch code blocks. Yeah, that's confusing. Since I catch the exception and show the appropiate messages, the application ends succesfully (return code = 0) even if the wrong arguments where sent and it didn't do anything. I need the package to know if the execution of the application failed, so that the task will fail and the work flow will stop.

What I did is remove the try/catch code, (or just threw an exception in the catch part) so that the task will fail and the flow will stop. This disturbs me. What is the best way to handle errors in these situations? And not just a call from a package but any call to the application from an external process. I know I could define error codes and exit the application with

C#

int errorCode = 10; 
Exit(errorCode);

but, the package still doesn't know that the application failed. I looked into Environment.FailFast(); but that seems to be pretty much the same as not doing anything (am I wrong?).

I don't want to leave exceptions unhandled because it feels dirty. What should I do?

Posted 19-Jul-13 17:51pm

Vic91

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Ron Beyer · Accepted Answer · 2013-07-19T18:03:00

Solution 1

I would fail with a generic error then write detailed failure info to the application log or an error reporting file.

Best practice for handling exceptions is to only handle exceptions that you can do something about it, the rest you pass up the call stack (aka, don't catch them). You can catch the generic Exception in the main function and return a failure code (-1) and write out detailed information to the log, which is somewhat acceptable since it prevents one of the ugly "Application Terminated Unexpectedly" messages.

Posted 19-Jul-13 18:03pm

Ron Beyer

Comments

Vic91 20-Jul-13 0:48am

Thanks! I thought something like that. Question though, are negative return codes standard for failure codes? Will my package read the return code as a failure and fail the task? From what I know, I think it wouldn't. Let's say that the main purpose of my application is to be called from an external process to run in the background and not be called from the command line. Should I, in this case, just let the exception terminate the application? I'm just wondering if it's worth getting the "Application Terminadted Unexpectedly" messages so that my packages will work ok, since I'm probably not going to call it regularly from a different source anyways. I thought that there might be a different way to tell that the application failed but still catching the Exceptions

Ron Beyer 20-Jul-13 0:55am

Personally, the "Application Terminated" message is a sign of a bug or poor programming. Your application should never show this or cause this to be shown. Typically this is only used if your application fails to respond to the Windows message pump.

Negative return codes are not standard, but then again no return codes are really standard. The only thing that is "standard" is that 0 means success, anything else is typically regarded as failure.

Don't let exceptions terminate your application, you should always exit gracefully even in an error. Especially if this is a headless design or an automated background process and the exception is really an "exception" and not a rule and you would expect the next run to operate correctly you should handle it and exit with a non-zero return code.

Vic91 20-Jul-13 0:58am

All right thanks. I'll see if I can detect the return code in the ssis package somehow

Sergey Alexandrovich Kryukov 20-Jul-13 1:02am

Good point and the way of explanation. It doesn't cover the topic of course; I would say, the good usage strategies require understanding of things under the hood, at least how stack and thread work. 5ed, anyway.
—SA

Sergey Alexandrovich Kryukov 20-Jul-13 1:10am

I just added some ideas in my own answer; I credited your answer, by the way.
—SA

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-07-19T19:09:00

In addition to the Solution 1:

One ultimate requirement to handling exceptions: catch them all on the top stack frame of each thread. Event-oriented UI threads have their own twist: all exceptions should be caught in the main even cycle of the thread. Usually, UI libraries have the special event invoked when such exception caught.

It does not mean that exceptions may not be caught in other places. Sometimes it is unavoidable, but the idea is to catch as little as possible. Main feature of exception handling is the isolation from the "regular" code. The over-catching is much more usual mistake then not catching. I call the places where the exceptions are handled the "points of competence". Read the Ron's answer to understand what it means.

One of the worse problem is catching the exception without doing anything (fixing a problem of re-throwing), which blocks further exception propagation. This is one of the worse mistakes, but there are rare cases where it is needed. This is sometimes should be done to compensate some defects in bad software libraries which don't have source code accessible for patching their problems.

[EDIT]

On the nature and main idea of exceptions, please see my past answer: Does Exception in C# Constructor Cause Caller Assignment to Fail?[^].

—SA