locked
How to handle errors? RRS feed

  • 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



    Wednesday, January 31, 2007 3:53 PM

Answers

  • 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.
    Thursday, February 1, 2007 10:15 AM

All replies

  • 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!

     

    Wednesday, January 31, 2007 4:56 PM
  • Just write a public static function that takes an Exception object as an argument.  Call that function from any catch handler.
    Wednesday, January 31, 2007 8:52 PM
  • 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


    Thursday, February 1, 2007 8:18 AM
  • 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().
    Thursday, February 1, 2007 8:55 AM
  • 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

    Thursday, February 1, 2007 9:09 AM
  • Throw an exception.  Try it, you'll like it once you get the hang of it...
    Thursday, February 1, 2007 9:37 AM
  • 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

    Thursday, February 1, 2007 9:56 AM
  • 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.
    Thursday, February 1, 2007 10:15 AM
  • Okay,

    thanks a lot!

    Henk
    Thursday, February 1, 2007 10:31 AM