Error handling

This is a discussion on Error handling within the C++ Programming forums, part of the General Programming Boards category; I searched the board and didn't find anything so I will pose the question to all of you. I am ...

  1. #1
    Registered User mepaco's Avatar
    Join Date
    Aug 2002
    Posts
    47

    Error handling

    I searched the board and didn't find anything so I will pose the question to all of you. I am quite new to c++ and my boss has me developing a class that will be in a dll. This class will be used by some other developers to build a GUI off of. My class interfaces to a driver to get system monitoring info. Basically I'm doing okay but I don't know what to do about error handling. I have things that might cause errors in my class. My class calls a function that might return errors. The function calls a driver that might return errors. I don't know how much info to return to the GUI and what the best way is. Basically, if anyone has any good sites or faqs or whatever that might help me a little with learning more about error handling I would appreciate it. Thanks.

    Edit: There is also a lot of dynamic memory allocation in my program. If anyone has good error handling stuff involving that I could really use it.

  2. #2
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    if you're talking about real error handling as in C++ error handling, look up try, catch, and throw. Otherwise I would say that the calls into your class could return success or failure values. I think that's what you mean.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  3. #3
    Registered User mepaco's Avatar
    Join Date
    Aug 2002
    Posts
    47
    Thanks FillYourBrain. I know about try, catch, and throw but I guess thats not really what I want to know. I want my class to be friendly in terms of errors. Lets say that the people developing the GUI use my class to get some info about the CPU temp. My class tries to allocate dynamic memory, calls a function which calls a driver and then returns the info into the memory. Well, if there is an error in there what should I do. How much info should I give the GUI. Should I just describe the general error? Should I tell them that it was an error returned by the driver or is that too much info? I guess really I just need some good info on the concepts of error handling in a professional way.

  4. #4
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    a lot of libraries will do something like this:
    Code:
    #define E_OK                              0
    #define E_ALLOCATIONFAILED   1
    .....
    #define E_BLAHBLAHERROR       100
    Then the user can always check for E_OK and if it's not, they can find out what went wrong (if they care).

    Code:
    int err;
    if(err = myobject.TrySomething())
       {
       switch(err)
          ......stuff......
       }
    Not a terrible way of handling it. What do you think?
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  5. #5
    Refugee face_master's Avatar
    Join Date
    Aug 2001
    Posts
    2,052
    Thats the way i'd do it, yet I rarely worry about error handling becuase I'm only 14 and make small, useless programs...
    Please direct all complaints regarding this post to the nearest brick wall Have a nice day.

  6. #6
    Seeking motivation... endo's Avatar
    Join Date
    May 2002
    Posts
    537
    Originally posted by mepaco
    Thanks FillYourBrain. I know about try, catch, and throw but I guess thats not really what I want to know. I want my class to be friendly in terms of errors. Lets say that the people developing the GUI use my class to get some info about the CPU temp. My class tries to allocate dynamic memory, calls a function which calls a driver and then returns the info into the memory. Well, if there is an error in there what should I do. How much info should I give the GUI. Should I just describe the general error? Should I tell them that it was an error returned by the driver or is that too much info? I guess really I just need some good info on the concepts of error handling in a professional way.
    I would accomplish this kind of thing by making the functions return bools. Suppose you have an init() function which allocates the memory, class the driver, etc. If at any point these actions are not completed then return false, otherwise all if good and return true.

    Another possibilty is to develop a heirarchy of exception classes which are thrown at various points in the code. Although that requires more work, so its up to you.
    Couldn't think of anything interesting, cool or funny - sorry.

  7. #7
    Registered User mepaco's Avatar
    Join Date
    Aug 2002
    Posts
    47

    Thanks guys.

    So the basic consensus is that returning a value that corresponds to a list of #defines or a typedef is the way to go. Sounds good to me. I'll just include different errors for driver errors and function errors and so forth. Thanks again.l

  8. #8
    Registered User mepaco's Avatar
    Join Date
    Aug 2002
    Posts
    47

    Endo,

    Is just returning bools enough info? I don't know how much information I should tell them. Like if my class can't allocate memory do I just return the same false value that I would return if the driver couldn't communicate with the hardware correctly. Like I said I'm very new to professional development so the more opinions I get the better.

  9. #9
    Refugee face_master's Avatar
    Join Date
    Aug 2001
    Posts
    2,052
    I think he meant to return a bool for each operation:
    Code:
    BOOL AllocateMem(...)
    {
       if(FAILED)
       {
            return FALSE;
       }
        return TRUE;
    }
    
    BOOL ComWithHardware(..)
    {
        // return true or false for this particular operation
    }
    Please direct all complaints regarding this post to the nearest brick wall Have a nice day.

  10. #10
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297

    Re: Endo,

    Originally posted by mepaco
    Is just returning bools enough info? I don't know how much information I should tell them. Like if my class can't allocate memory do I just return the same false value that I would return if the driver couldn't communicate with the hardware correctly. Like I said I'm very new to professional development so the more opinions I get the better.
    I like giving more info personally. This allows the user to throw up a dialog or log an appropriate message. You can't really go wrong by giving more info as long as only one value means true (as in E_OK or E_SUCCESS).
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  11. #11
    Registered User mepaco's Avatar
    Join Date
    Aug 2002
    Posts
    47
    Thanks for the input guys. After talking it over with my boss he said to go with the #defines. So here I go.

  12. #12
    Registered User xds4lx's Avatar
    Join Date
    Nov 2001
    Posts
    630
    Well you can have a main init function that calls other functions which return bools and actually set up their individual parts of the system, sound, graphics, memory, ..... and then if one of those fails return the defined error value from the init function.
    "only two things are infinite, the universe and human stupidity, and im not sure about the former." - albert einstein

  13. #13
    Seeking motivation... endo's Avatar
    Join Date
    May 2002
    Posts
    537
    Originally posted by xds4lx
    Well you can have a main init function that calls other functions which return bools and actually set up their individual parts of the system, sound, graphics, memory, ..... and then if one of those fails return the defined error value from the init function.
    Yup thats just what I mean. You could also return different values to tell you what failed, but then the user of the class needs to know a bit more about how to use it. Its swings and roundabouts really...
    Couldn't think of anything interesting, cool or funny - sorry.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21