#1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2001
    Location
    Phoenix, AZ
    Posts
    484
    Rep Power
    36

    How to handle memcpy exception?


    Newb here, proceed with caution!

    In some code on a server where I work, we found that an exception occurs on a line with memcpy. The reason is that the source buffer (when all the stars were aligned just right) had FAR more characters in it than the destination buffer had allocated. So it overwrote something in memory and the application just disappeared with no indication why.

    So obviously the lengths should be checked for feasability before attempting the memcpy. However, this was inside a __try __except block but it doesn't seem to have been trapped.

    There must be a way to trap for this kind of exception. Where would I go to learn how to set up some better exception handling? Books, on line resources, etc.

    Tx!
    There are only 10 kinds of people in this world. Those who understand binary, and those who don't!
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Feb 2001
    Posts
    1,481
    Rep Power
    15
    Hi,

    A try block throws a certain type of exception, and the exception catch block must be defined to catch that type. If the catch block does not have a parameter that matches the type of what was thrown, then the catch block is skipped. If you want, you can change the parameter of the catch block to an all encompassing parameter:

    catch(...)
    {
    }

    will catch any exception thrown. Or, you can write an additional catch block yourself, which catches the specific exception you saw occur. You do that just like you would write a function:
    Code:
    try
    {
        if(strlen(to_be_copied) > declared_length)
           throw "This is that damn error!"
    }
    
    catch(const char* message)
    {
        cout<<message<<endl;
    }


    I would proceed with the second option, so you don't mess up any catch block system in place that routes exceptions to different catch blocks. If an exception thrown in a try block is not caught by any catch blocks, then the standard library function terminate() is called. That function calls a predefined default terminate handler, which in turn calls the standard library function abort(). You're able to redefine the default action of the default terminate handler to do a few things before it calls abort() if you need to.

    Books: "Ivor Horton's Beginning C++", Chapter 17: Program Errors and Exception Handling. It's a great reference and tutorial, so it's a good book to have.

    If you want more help on determining what type of exception is thrown, post the try block and put a notation by the line that does the throwing, and we can help you write a catch block.
    Last edited by 7stud; May 22nd, 2003 at 08:30 PM.
  4. #3
  5. Banned ;)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Nov 2001
    Location
    Woodland Hills, Los Angeles County, California, USA
    Posts
    9,638
    Rep Power
    4247
    Related article:
    http://support.microsoft.com/default...en-us%3b315937

    Hope this helps :)
  6. #4
  7. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,174
    Rep Power
    2222
    Uh, wait a minute. When you call memcpy, you specify the number of bytes to be copied. After you have allocated the destination buffer. You will be in a position to know both the size of the destination buffer and the number of bytes that you will be copying to it.

    That's no exception; that's a programming error. Correct the error and recompile.


    In school, our IBM S/370 documentation had a thick manual listing the system error messages. The cause of the error and the corrective action seemed to always be the same: programming error; correct the code and resubmit the job.
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2001
    Location
    Phoenix, AZ
    Posts
    484
    Rep Power
    36
    7stud,

    Thanks, I'll play with that. I have Ivor's "Beginning Visual C++" and I'll look for and read the exception chapter asap.

    Scorp, wow, that one will require some study. Thanks!

    dwise, right, it's a programming error. In fact it's a logic error. Either way it's an opportunity to learn how to properly trap for errors. Remember, this is not my code and i'm learning c++ but am fluent in several other languages. I can always correct the logic and recompile. In fact, I can do that until the cows come home. But, since programmers are never perfect, code should always trap for problems. In this particular case, the server should have notified us of an issue rather than just disappearing from existance. Doh!

    Thanks guys! Of course we have corrected that logic problem, but I will learn how to better trap for exceptions and instute that into the existing code.
    There are only 10 kinds of people in this world. Those who understand binary, and those who don't!
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Feb 2001
    Posts
    1,481
    Rep Power
    15
    "Thanks, I'll play with that. I have Ivor's "Beginning Visual C++" and I'll look for and read the exception chapter asap."

    That's not the same book. Out of necessity, the C++ chapters in "Visual C++" are very cursory. Check p. 213 in that book for a short discussion on exceptions.

IMN logo majestic logo threadwatch logo seochat tools logo