Limit Use Of Exception For Control Flow In Handling Post Requests

Yii 1.1 General Discussion
1

While I know that the use of Exceptions for control-flow is generally a bad idea, I can’t help but think of all the advantages that would come with it during the POST handling code in actions.

Take the typical scenario:





if (isset($_POST['Foo'])) {

    $foo->setAttributes($_POST['Foo']);

    if($foo->validate(){

        if ($foo->save()) {

            $messages['success'] = "notify user it was successfull"

        } else {

            $messages['error'] = "notify user of unexcepted error"

        }

    }  else {

        $messages['error'] = "notify user that his fields are invalid"

    }

}

Reimagined with Exceptions, where ValidationException and SavingException extend the PostHandlerException:




if (isset($_POST['Foo'])) {

    try{

        $foo->setAttributes($_POST['Foo']);

        if(!$foo->validate()){

            throw new ValidationException(); // this has the msg alerting users to check the field

        }

        if(!$foo->save()){

            throw new SavingException(); // this has the msg alerting users that something went wrong, and logs it

        }	

        $messages['success'] = "notify user it was successfull"

    }catch(PostHandlerException $e){

        $messages['error'] = $e->getMessage();

    }

}

This way, regular ("real") exceptions are still handled as before, but the code is more easily read (as you can see the consequences of a negative action directly, and not below X lines of code before the else statement), and easier maintained, it seems to me. It might not be clear from this trivial case, but it is not uncommon (in some of our production code) to have 3-4 levels of nested ifs before an action is finally handled (e.g., saved).

Or am I just delusional and this remains a a code smell ?

2

I don’t see any real benefit of throwing an exception and stoping the execution, what if the user wants to go back and correct the errors

3

The proposal here is to catch he exception and update the message list. It still allows the user to correct the errors as no error page is displayed if all relevant errors are catched.

IMHO using exceptions this way or not is a question of style.

Exceptions are ofthen expensive (in terms of time), so I try to avoid their use, unless using exceptions is a real timesaver.

Exceptions are also useful as it is a way to propagate errors no matter how deep the call without the need to mention an explicit parameter. However, Java does better on this as it requires that you specify the exceptions a method may be throwing. I prefer that as it helps managing the exceptions you need to catch.

Thus my personal guideline is to use exceptions sparsely and only for events that are not supposed to occur if the program runs well. Even with bad user input, there should not be an exception.

I only deviate from that rule if using exceptions is the only way or if it is a real timesaver (development wise). I would consider that this is not the case for the given example.

4

@let_top I did not notice this right here


ValidationException and SavingException extend the PostHandlerException