How to handle errors?

Question

Hello,

If some programming state is not okay (like finding that a SerialPort is not open prior to sending data) I would like to show some error message.

I would like to handle all error messages-displaying in a central place by a single function.

How do I achieve this? (As a newby in C#, in Borland C++ I was used to use a global string for storing the error messgae which is displayed when all nested functions return false).

But C# does not allow a global string(?), or what other mechanism is usually applied for this purpose?

All tips and hints are welcome.

regards,

Henk

Answer 1

Henk

You can certainly have global variables in C# it's just that the scoping rules are a little different than C++.  It's all about how you architect your classes to interact with each other.  A class marked static does not need to be substantiated.

In a Windows application there is an event of the Application class that will receive any unhandled exceptions:

Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException);

Using this you can support a crash dialog (We're sorry, this applicaiton needs to close, press this button to send an error report).

The common practice is to wrap exception potential code in try / catch blocks rather than one giant generic exception handler.  This lets you get very specific about different exceptions:

try

{

}

catch permission exception { }

catch I/O exception { }

catch FIle Not Found exception { }

etc.

There are several good examples of different exception handling schemes in the patterns and practices library on msdn.microsoft.com that will give you some other ideas.

HTH!

 

Answer 2

Just write a public static function that takes an Exception object as an argument.  Call that function from any catch handler.

Answer 3

Okay thanks,

but what should I use if a user-handling-error has occurred that is detected by the program  (needing some user-instruction) and not a programming-error detected by the run-time-error-detector (;-) )

//Example: save an info message when serialport is not open
bool SendStringToSerialPort(string s){
if(!SerialPort.IsOpen){
MyGlobalInfoString="Select and open a SerialPort first";
return false;
}
else{
SerialPort.SendString(s);
return true;
}

I use boolean functions as much as possible so if any (deeply) nested function fails, program flow is returned to the mainfunction which should then show the info message.
//example
MainFunction(){
if(!FuncA){
ShowUserInfoMessage(MyGlobalInfoString);
}
bool FuncA(){
if(!FuncB){
 return false;
}
bool FuncB(){
if(!SendStringToSerialPort("Test"){
 return false;
}

Question1:
is this boolean use of functions good programming?
Question2:
if so, should I also use the Exception mechanism for this user-info-message purpose?

regards,

Henk

Answer 4

Q1: no, that's something you did back in the bad old days before exceptions became available.  You'll pretty much end up with almost every procedure being a function returning a boolean.  That is in fact how COM works.  Ignoring a False return is the classic bug.

Q2: no, exceptions are meant to change the flow of your program, not to inform the user.  Just use MessageBox.Show().

Answer 5

It's nice to learn from an expert, I will replace my boolean functions.

But still I have a fundamental question.

If the SerialPort is not open I think it's useless to have the remaining code in the calling function (FuncB in my example) executed. How do I avoid the remaining code in FuncB being executed?

Henk

Answer 6

Throw an exception.  Try it, you'll like it once you get the hang of it...

Answer 7

So I should try/catch in function 'MainFunc' or in 'FuncA' or in 'FuncB' and throw in 'SendStringToSerialPort'?

is that correct?

I think I'm going to like throwing, just getting used to it....

Henk

Answer 8

You catch at a point where something can be done about the problem.  Why is the port not opened?  A problem with the hardware or something like that: catch at the end of the Main function or not catch at all; the program should terminate.  The user forgot to do something: catch and report in the user interface handling code; the user can correct and retry the operation.

Answer 9

Okay,

thanks a lot!

Henk