Catches win matches... they say

tumbledDown2earth

Found this in a would be production code today ...

public bool InitializeApp()
{
// Log

bool bStatus = false;
try
{
    // step 2 :
    try
    {
        DoStep2();
    }
    catch (Exception ex)
    {
        // Log ex
    }

    // step 3 :
    try
    {
        DoStep3();
    }
    catch (Exception ex)
    {
        // Log ex
    }

    // step 4 :
    try
    {
        DoStep4();
    }
    catch (Exception ex)
    {
        // Log ex
    }

    // step 5 :
    try
    {
        DoStep5();
    }
    catch (Exception ex)
    {
        // Log ex
    }

    // step 6 :
    try
    {
        DoStep6();
    }
    catch (Exception ex)
    {
        // Log ex
    }
}
catch (Exception eError)
{
    // Log -- God knows how can some code get in here -- unless a Log exception throws
}

return bStatus;

}

Goes without saying that every DoStep method has a try-catchEverything block with log If I am still missing the point .. its the nested try-catch I am pointing to :laugh:

PIEBALDconsult

I've had to do that in certain circumstances. Use the right tool for the right job.

lewax00

It's not that bad, unless each step depends on the previous step completing successfully, in which case there's no reason to run the rest when you know they will fail.

AlphaDeltaTheta

Well, I always have an Uncaught Exception Handler. I program mostly in Java and C# and I don't like any hangs or crashes. get an uncaught handler, if at all an exception occurs, (yes... I give heed to LogException too) if is shown as - "POSSIBLE BUG... Please help us to fix it by sending a brief bug report"...

Bernhard Hiller

I also like the fact that it will always return false. Did you miss this most important feature? :)

tumbledDown2earth

:)) good eyes

Rob Grainger

Can you elaborate? I find it hard to conceive of a situation where that would be necessary, but am willing to be proved wrong.

"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

PIEBALDconsult

What came to mind was a Windows Service I wrote a few years back that had to perform a number of related, but not dependent, tasks. An analog that also came to mind was babysitting... the babysitter will have a number of tasks: 0) Check the kid's homework 1) Feed the kid 2) Put the kid to bed A problem in one task doesn't mean you can't perform the others: If the kid doesn't do the homework or has errors, you still feed him. If the kid doesn't eat his vegetables, you still put him to bed. Just log it and continue. If the problem is bad enough, alert the parents, but don't go running out of the house.

Lutoslaw

Food is a reward for doing the homework. I will be a terrible parent.

Greetings - Jacek

Gaston Verelst

Looks like on error resume next

jbojarczuk

One use for such a structure would be to fully log the error without having debuging info in the compiled form. If that is the case, then the outer try/catch would be the unnecessary one, not the internal ones.