CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 19
  1. #1
    Join Date
    Feb 2009
    Location
    Portland, OR
    Posts
    1,488

    __try and CStringArray conflict

    I'm so tired of this error, and I hope someone can clarify it for me. Say, I have the following:
    Code:
    CStringArray arr;
    ...
    __try
    {
    }
    __finally
    {
    }
    For some reason this combination produces an error:
    Cannot use __try in functions that require object unwinding
    I end up not using the exception handling at all to make it go away, but that's not right. What shall I do instead?

  2. #2
    Join Date
    Nov 2003
    Posts
    1,902

    Re: __try and CStringArray conflict

    Why not keep it standard with try/catch(...)?

    gg

  3. #3
    Join Date
    Feb 2009
    Location
    Portland, OR
    Posts
    1,488

    Re: __try and CStringArray conflict

    Because it doesn't have __finally.

  4. #4
    Join Date
    Apr 1999
    Posts
    27,449

    Re: __try and CStringArray conflict

    With the proper use of RAII, __finally is not necessary in a C++ program. If an object is destroyed, then its destructor should do the clean up.

    Regards,

    Paul McKenzie

  5. #5
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: __try and CStringArray conflict

    I think the issue is that
    __try / __except / __finally
    Are for structured exception handling (hardware errors and OS errors, such as division by zero, accessing uncommitted memory etc).

    while try/catch is for C++ errors, where some other piece of code explicitely did a 'throw <something>'.

    try/catch should not trigger on OS exceptions (an older version of VC++ did), and __try/__except doesn't work with C++ exceptions

    They serve distinct purposes...

    try/catch does stack unwinding, __try does not, this is why the compiler rightfully tells you what you're trying can't be done.

    You'll need to change the way the function is programmed to get this to work.

    In this case, you could new the CStringArray rather than have it as a local object. and delete it at the end of the function yourself. But that violates the RAII rule of course. But then the big issue of course is that RAII and SEH don't work well together in any cas eyou turn it.

  6. #6
    Join Date
    Nov 2003
    Posts
    1,902

    Re: __try and CStringArray conflict

    More specifically, I was referring to "/EHa" (asynchronous exception handling model).
    Code:
    #include <iostream>
    using namespace std;
    
    struct bar
    {
        int m_n;
        explicit bar(int n) : m_n(n) {cout << "bar(" << m_n << ")" << endl;}
        ~bar() {cout << "~bar(" << m_n << ")" << endl;}
    };//bar
    
    void foo()
    {
        bar b(2);
        int *p = 0;
        *p = 0;
    }//foo
    
    int main()
    {
        try
        {
            bar b(1);
            cout << "Calling foo" << endl;
            foo();
        }//try
        catch (...)
        {
            cout << "OOPS" << endl;
        }//catch
    
        return 0;
    }//main
    Code:
    bar(1)
    Calling foo
    bar(2)
    ~bar(2)
    ~bar(1)
    OOPS
    http://msdn.microsoft.com/en-us/library/1deeycx5.aspx

    gg

  7. #7
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: __try and CStringArray conflict

    Catching Structured exceptions via the C++ exception model is a REALLY bad idea. I strongly suggest you never ever use it. I also suggest you never ever use catch (...).

    Using it in test code is ok enough, but when used in production/release code, you're only going to make you pull out your hair in agony when things start going bad.



    We had a big discussion on catch(...) a while back, and I strongly disagree with any argument you can give for it's possible 'good' use. Catching an exception but then not being able to give even the slightest hint at what actually went wrong is just signs of a bad programmer, or being bad at choosing to bet your personal reputation on a library that is badly designed.

  8. #8
    Join Date
    Nov 2003
    Posts
    1,902

    Re: __try and CStringArray conflict

    >> Catching Structured exceptions via the C++ exception model is a REALLY bad idea.
    ??? I fail to see any evidence supporting such a strong statement...

    If an exception is thrown, you either catch it or you don't. Choosing how you catch it is of little consequence.

    gg

  9. #9
    Join Date
    Feb 2009
    Location
    Portland, OR
    Posts
    1,488

    Re: __try and CStringArray conflict

    Thank you, guys. But I'm kinda confused. What is the difference between the following?
    Code:
    try{
    }
    catch(...){
    }
    Code:
    __try{
    }__exception(){
    }__finally{
    }
    and
    Code:
    TRY{
    }CATCH(){
    }

  10. #10
    Join Date
    Nov 2003
    Posts
    1,902

  11. #11
    Join Date
    Feb 2009
    Location
    Portland, OR
    Posts
    1,488

    Re: __try and CStringArray conflict

    OK, thanks. Very useful info! It doesn't let me rate you for some reason.

    But, it doesn't help my confusion. I quickly looked through those links you gave, and my question is, which one shall I use?

    Say, if I use TRY/CATCH type, does it mean that it will catch only MFC-type exceptions? Or do I need to encase it into a try/catch or __try/__exception/__finally block?

    Don't get me wrong, but all that exception handling is quite annoying and I'd greatly appreciate if I could use only one set of commands for all the situations. You see my point?

  12. #12
    Join Date
    Nov 2003
    Posts
    1,902

    Re: __try and CStringArray conflict

    I can't speak for MFC's macro's. Otherwise I would only use SEH if you have a really good reason for doing so. Utilizing __finally (in C++) isn't one of them.

    gg

  13. #13
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: __try and CStringArray conflict

    Quote Originally Posted by Codeplug View Post
    >> Catching Structured exceptions via the C++ exception model is a REALLY bad idea.
    ??? I fail to see any evidence supporting such a strong statement...
    because you can only catch them with catch (...) which means you have absolutely no indication WHY or where it failed.

    If you get called middle of the night to go fix a "undefined error occurred" in a important running project, you'll probably change your mind as well. Especially if you then figure out those undefined errors can happen in any of several dozen locations.


    If an exception is thrown, you either catch it or you don't. Choosing how you catch it is of little consequence.
    well this is where I disagree.
    If you can catch what was thrown, then you catch that thing specifically.

    If you can't catch what was thrown and resort to a big catchall, you're better off not catching at all.

    I'm actually using the "what is a good reason to use catch (...)" in my job interviews for new programmers, it's amazing what kind of answers you get, and stomping out 'bad' practice is the first thing we do in the job training when they do get hired.

  14. #14
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: __try and CStringArray conflict

    Quote Originally Posted by ahmd View Post
    Thank you, guys. But I'm kinda confused. What is the difference between the following?
    Code:
    try{
    }
    catch(...){
    }
    Code:
    __try{
    }__exception(){
    }__finally{
    }
    and
    Code:
    TRY{
    }CATCH(){
    }
    don't use TRY/CATCH, it's obsolete
    use try/catch for catching C++ errors
    use __try __except __finally to handle hardware/OS exceptions.

  15. #15
    Join Date
    Feb 2009
    Location
    Portland, OR
    Posts
    1,488

    Re: __try and CStringArray conflict

    Quote Originally Posted by OReubens View Post
    don't use TRY/CATCH, it's obsolete
    use try/catch for catching C++ errors
    use __try __except __finally to handle hardware/OS exceptions.
    That's the kind of an answer I needed. Thank you!

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured