Guidance on sequential Error Handling

[web1928]

Hi guys. In my script I have a number of dependent executions. Some are db related, some are not.

I am trying to implement the most efficient error handling methodology I can, according to my current capability, but something is bugging me in terms of the script sequence.

I wrap each code block in a try/catch, but then for subsequent, I have to either nest the try/catches or wrap each in an if(); statement.

What would make more sense to me would be the ability to have multiple try{} blocks that throws to an end catch(), jumping over all other code. I am currently lookin into the goto method, but not sure if this is best practice?

Here is an example of what I mean:

try {
    // execute code block.
    // If all good, script continues to next try{}
    // If it breaks, throws to catch.

} catch(Exception $e) {

    $errorMsg[] = $e->getMessage();

    // ** My problem now is that I don't want the next 2
    // ** code blocks to be executed so I have to wrap
    // ** them in an if() or nest these try{}'s.
    // ** This is okay for a couple of code blocks
    // ** but looks messy when there are many
}

if(count($errorMsg) === 0) {

    try {
        // execute 2nd code block

    } catch(Exception $e) {

        $errorMsg[] = $e->getMessage();
    }
}

if(count($errorMsg) === 0) {

    try {
        // execute 3rd code block

    } catch(Exception $e) {

        $errorMsg[] = $e->getMessage();
    }
}

My thought on the goto would be to include it in each catch() and sent it to the appropriate label: jumping whatever code it should.

I hope my question makes sense.

Regards

/Danny

[phdr]

Don’t use goto, ever.

dependent executions

I suspect a solution will be to use an associative index name in the $errorMsg[…] array, that you can specifically test for the absence of at a dependent block of code, but it would take seeing a specific example of what you are trying to do to be sure.

[skawid]

This looks like you’re only ever going to run until you get a single error. If that’s the case, you only need one try...catch block:

try {
    // execute 1st code block.
    // execute 2nd code block
    // execute 3rd code block
} catch(Exception $e) {
    $errorMsg[] = $e->getMessage();
}

Does this work as you expect?

[web1928]

Revisiting my code, there is opportunity to merge some of the code blocks within the same try/catch, but still others where there is code embedded between, where it is not feasible.

I am perhaps overthinking, programmatically, and should appreciate that there will be a need to nest code blocks or wrap them in conditional statements. Where this looks cumbersome, it shall be more of a learning experience to try and build smarter code structure, I guess.

One of the biggest obstacles (I guess facing any beginner/intermediate) is the transition to OOP, which would help a lot with my code structure overall. While I am still at the early stages of implementing OOP, the application(s) I am working on are of such low complexity, it is less hassle just to structure procedurally.
note to self: that’s laziness on my part, as even with low complexity applications, building objects would help me learn!

Key takeaway for me today is… don’t use goto !

/Danny

[skawid]

OOP is widely used in PHP, but it’s just another tool and won’t necessarily help you improve on its own - bad OOP code is still bad code. If a procedural approach can handle the complexity of your task, you’d be better off improving other aspects of your work than you would trying to shoehorn it into objects.

[benanamen]

Key takeaway for me today is…

Another take away: There is no need to litter your code base with try/catch blocks. Php is more than capable of handling errors on it’s own. I was once guilty of it myself until I learned better.

There are really only two cases where you would want to use try/catch. That would be a DB connection failure and a duplicate user being added to the DB. Other than that, let Php handle it.

You can also use set_exemption_handler to customize the handling of exceptions.

[web1928]

Thanks for the pointers, guys. Both good points and something I’ll consider.

Never thought about it like that, benanamen; I’ll look into the set_exemption_handler() function.

I guess that the key thing for me is that errors are off on the live site (so they don’t display sensitive server data to the end user. Also, that the end user is not just left looking at a blank or half page, wondering what has happened, if the code does tip over.

/Danny