Does try finally statement work???



  • I have the following statement which resulted in ¨error: expected ‘catch’ before ‘finally’¨
    @
    try
    {
    mutex.lock();
    }
    finally
    {
    mutex.unlock();
    }
    @



  • Are you sure that you want to use exceptions?



  • Well,

    maybe you're confusing Delphi with C++ :)

    You don't have try .. finally structure in C++, cause it's useless. Equivalent form of Delphi try ... except is try ... catch.

    T.

    P.S.: Use "QMutexLocker":http://doc.qt.nokia.com/4.7/qmutexlocker.html in your case.



  • I like try finallys, I wouldn't say the're useless. I use them for these kinda sanity checks (assuming they magically existed in C++):

    @void myProc()
    {
    mutex.lock();
    try
    {
    if (condition1Fails)
    return;
    if (condition2Fails)
    return;
    if (condition3Fails)
    return;
    doStuffSafely();
    }
    finally
    {
    mutex.unlock();
    }
    }@

    It reads easier and is much more elegant than this:

    @void otherProc()
    {
    mutex.lock();
    if (condition1Passes)
    {
    if (condition2Passes)
    {
    if (condition3Passes)
    doStuffSafely();
    else
    mutex.unlock();
    }
    else
    mutex.unlock();
    }
    else
    mutex.unlock();
    }@

    I should add that (not shown here) the conditions sometimes require intermediate values to be calculated that can't fit into a single expression.

    I guess one could also introduce a boolean variable, but is there any simpler way to structure such a piece of code when try..finally is absent?

    Unfortunately in some languages (objective-C) they implemented finally but didn't add the rule that when using return, break or continue the finally part is guaranteed to execute.



  • You have to use "catch" block before finally because it's originally: try-catch, not try-finally.

    For example:
    @
    try {
    // try something
    }
    catch() {} // Nothing to do
    finally {
    // Do something
    }
    @
    But it's not pretty system to check something.



  • An commonly used pattern to achieve this without exception support is:

    @
    mutex.lock();

    do {
    if (condition1Fails)
    break;

    if (condition2Fails)
    break;

    if (condition3Fails)
    break;

    doStuffSafely();
    } while(false)

    mutex.unlock();
    @

    Also have a look at "QMutexLocker":http://doc.qt.nokia.com/4.7/qmutexlocker.html and its ReadLocker and WriteLocker friends. They unlock the mutex once they go out of scope.



  • Volker, thanks for the excellent suggestion! I never thought of that pattern.



  • No problem, you're welcome. I learned of it only some years ago, so it's actually not my invention :-)



  • Well, QMutexLocker is just a specialization of RAII technique. If well used, you can say "bye" to any try..finally or try..catch method.

    "Resource Acquisition Is Initialization":http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization



  • With regards to mutex I do think using an RAII technique (I had to click on the link to make sure it was what I thought it was) is most elegant, but my argument applies to anything that must finally be wrapped up which may not have an RAII class available for it (and it would be silly to create one to be used only once).

    But after discovering the technique Volker posted about I am happy not to have try finally :) And I can use this in Objective-C as well!



  • With a bit of template magic, you can make a RAII class that you can use for more than one purpose. Still, even without that, it can make perfect sense to create a RAII class that you only use at a single place. It is not like they take a lot of code to write, just a few lines usually does it. If you end up with code like Eonz showed before:

    @
    void otherProc()
    {
    mutex.lock();
    if (condition1Passes)
    {
    if (condition2Passes)
    {
    if (condition3Passes)
    doStuffSafely();
    else
    mutex.unlock();
    }
    else
    mutex.unlock();
    }
    else
    mutex.unlock();
    }
    @

    you know you need a RAII class to make this readable and maintainable again. There is one ready made for mutexes, but they also make perfect sense for many other cases too.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.