How do you handle user errors in your design

[EscapeYourMind]

I'm looking for some opinions on what you guys do with user errors and where you handle them in your design. Take for example a login form, obviously you want to make sure something was entered into both the username and password field, and you also need to see if they are valid. Now, the main question is how do you go about handling it when a field is left blank or the username/password are not found? Do you just use trigger error? If you do, how would you have this setup in your application design if the login error pages were different from ones deeper in the site? Where would your error handling class be at in your design, and how would you control the view for it? Additionally, if you just redisplay the login form with an message stating the error, like a field was left blank, how do you handle that on all your pages to accept a message? Wouldn’t you need to send something through get or post since a request has to be sent again for the page?

I'm having some problems figuring out how to handle user errors in my application. I know about exceptions but I like the separation between using exceptions for truly exceptional issues, and ones that are clearly a user error that is expected to happen. So if anyone would like to share how they handle this stuff, or offer any ideas to help it would be greatly appreciated.

[sweatje]

$_SESSION based error queue.

Wrapped inside of a monostate object to add, retrieve or clear the queue.

Gets around the most basic problem of delaying the display of the error until a step in the processing where you are displaying data for the user.

[champ]

I agree with sweatje. For my setup I use the array $_SESSION['errors'] to hold all my errors.

During form validation, you could store the errors like so:

if (!is_invalid_username($_POST['username'])) {
    $_SESSION['errors'][] = 'Username is invalid';
}
if (!is_invalid_password($_POST['password'])) {
    $_SESSION['errors'][] = 'Password is invalid';
} 

You can then echo this in your view. You can even put the below in your main template so it's reflected on all pages:

if (!empty($_SESSION['errors'])) {
    echo '<ul>';
    foreach ($_SESSION['errors'] as $error) {
        echo '<li>' . $error . '</li>';
    }
    echo '</ul>';
} 

Remember to unset/reset the $_SESSION['errors'] variable before performing form validation, and when you no longer need it.

Keep in mind, the above is just a generic approach for the sake of clarity.

[EscapeYourMind]

Just to clarify something, you both are using the form of displaying errors where you will display the error on a page which also has the form on it again correct? Your not using the form where as soon as an error is generated a redirect is called to an error page?

Are there any pros/cons to handling errors each way? In the past (before I started working entirely with oop) I just used a custom error handling function (with set_error_handler), and then whenever a form field wasnt correct in that rule I would use trigger_error() which would clear anything that was already added to the output buffer, and instead create an error page in its place. But I'm not sure that way has the flexibility I need anymore.

[champ]

Are there any pros/cons to handling errors each way?.

Trigger error is more for your knowledge (eg, error logfile) than the visitor's. Showing them the internal php error messages would confuse them and is a security threat.

By redirecting back to the form and showing the $_SESSION-based errors, would be most convenient to the user, as well as expected behavior. You'll also have the opportunity to echo the form values they filled out, rather than erasing them all after redirection.

During the validation process you could create a dedicated $_SESSION['formvars'] variable and store values as such:

$_SESSION['formvars']['username'] = $_POST['username']; 

Then echo them onto the page with something such as:

<?php
function escape(&$var)
{
    if (isset($var)) {
        return htmlspecialchars($var, ENT_QUOTES);
    } else {
        return '';
    }
}
?>

<input type="text" name="username" value="<?php echo escape($_SESSION['formvars']['username']); ?>" />

[foofoonet]

Perhaps I am behind the curve on this.

I use JS to snag as many user errrors as possible client side. Why worry about piping messages around your mvc app?

Anyone who gets past those, and still submit errors is treated as a potential cracker, logged out and their account closed.

The only error handling I really want is that which shows me that I (or someone) has incorrectly applied the api.

No JS? You can't even login and use my app.

Now - before the hackles are raised, heads thrown back and gullets emit howls moonwards.... I am talking about Admin only areas of CMSs, CRMs kinda thing - not public application for child benefits... But thats mainly what I do.

[GeertDD]

I store all the errors in a $formerrors array, much like sweatje's and champ's approach. Actually, I don't really get the advantage of using $_SESSION for storing the errors since you get the extra work the unset/reset them.

To go one step further I take the name of the form element as the key for the $formerrors array. This way allows you to highlight the form fields with errors as well, instead of only displaying error messages at the top. Simplified example below.

if ($_POST) {

  // check username field
  if (empty($_POST['username']))
    $formerrors['username'] = 'You need to enter your username.';
  elseif (!regex_username($_POST['username'])
    $formerrors['username'] = 'You supplied an invalid username.';
  // check all other fields...

  // all checks completed, but not passed
  if (!empty($formerrors))
    $tpl->set('formerrors', $formerrors);
  // all checks passed
  else { /* log user in for example */ }
} 

<!-- loop through all error messages first -->

<!-- then highlight the specific fields -->
<p <?php if (!empty($formerrors['username'])) echo 'class="alert"'?>>
  Username:
  <input name="username" type="text" />
</p>

[kyberfabrikken]

I store all the errors in a $formerrors array, much like sweatje's and champ's approach. Actually, I don't really get the advantage of using $_SESSION for storing the errors since you get the extra work the unset/reset them.

It allows you to redirect to a GET request after POST, which will prevent people from re-submitting the form if they hit reload.

[EscapeYourMind]

It seems like a lot of people use the way that displays the errors along with the form page again, instead of just displaying an error page. What cache-control header do you use, or rather how do you keep the form fields filled out after you redirect the user back to the form?

Also, would it be a good idea to use a combination of the different methods? Like use exceptions for the exceptional cases, like a file not found or database couldnt be connected. Use trigger_error() which would bring up an actual error page for non-form based errors, and then use a $_SESSION array for form validation errors?

[GeertDD]

It allows you to redirect to a GET request after POST, which will prevent people from re-submitting the form if they hit reload.

Hmm, makes sense. I'm wondering though whether this is a reliable way to show errors. What happens if a user completely blocks cookies?

[sweatje]

Hmm, makes sense. I'm wondering though whether this is a reliable way to show errors. What happens if a user completely blocks cookies?

Do you use $_SESSION for anything?

[33degrees]

Hmm, makes sense. I'm wondering though whether this is a reliable way to show errors. What happens if a user completely blocks cookies?

By default, PHP's session mechanism will add a session id to all urls if it can't use cookies.

[kyberfabrikken]

It seems like a lot of people use the way that displays the errors along with the form page again, instead of just displaying an error page. What cache-control header do you use, or rather how do you keep the form fields filled out after you redirect the user back to the form?

I store the form fields in session until the form is valid.

Also, would it be a good idea to use a combination of the different methods? Like use exceptions for the exceptional cases, like a file not found or database couldnt be connected. Use trigger_error() which would bring up an actual error page for non-form based errors, and then use a $_SESSION array for form validation errors?

trigger_error and exceptions are alternatives - it doesn't really make sense to mix them, even if it's possible. They are both meant as mechanisms for handling runtime errors, not business rule violations (user errors). I think it's a good idea to deal with user errors as a part of the normal flow - eg. from an application perspective, it's expected to happen, and not treated as an error per se.

Hmm, makes sense. I'm wondering though whether this is a reliable way to show errors. What happens if a user completely blocks cookies?

It's not REST proper, but I can live with that, as long as we're talking html-based web applications.

[EscapeYourMind]

Ok, I've got a few more questions, what if you are using a Request object or dataspace that stores the $_GET and $_POST variables? How would that work with a $_SESSION based error queue where you store the variables in the $_SESSION to re-fill out the form and display the errors?

Also, do you run all rules against all the fields on a form and display all the errors encountered, or do you display the first error and go back to the form? At first it sounds like the first one would be the best, but what about instances where errors cause other errors to occur? Do you just accept the fact that it would happen, and may be slightly confusing for the user?

[schnoodles]

Also, would it be a good idea to use a combination of the different methods? Like use exceptions for the exceptional cases, like a file not found or database couldnt be connected. Use trigger_error() which would bring up an actual error page for non-form based errors, and then use a $_SESSION array for form validation errors?

In my opinion that is how it should be done, seeing they are all different types of errors, and exception and trigger errors are at a higher level so you would want to handle them differently.

My only question with this is, what is the spead like with sessions. Seeing you could be using a numerise amounts of them.

[33degrees]

Also, do you run all rules against all the fields on a form and display all the errors encountered, or do you display the first error and go back to the form? At first it sounds like the first one would be the best, but what about instances where errors cause other errors to occur? Do you just accept the fact that it would happen, and may be slightly confusing for the user?

You can simply display just the first error for a given field; less confusing then having them all, but more informative than just one, as you really want to avoid having the user fix errors one by one, reloading the page each time.

[champ]

Ok, I've got a few more questions, what if you are using a Request object or dataspace that stores the $_GET and $_POST variables? How would that work with a $_SESSION based error queue where you store the variables in the $_SESSION to re-fill out the form and display the errors?

I don't see how it would make a difference. The $_POST values are temporary and will be forgotten once you transfer the user back to the form to correct the errors. Wrapping it in a request object still won't make it persist across page requests. That's why you hold the form vars in a $_SESSION for later usage.

Also, do you run all rules against all the fields on a form and display all the errors encountered, or do you display the first error and go back to the form?

That's how it's typically done, because it's expected behavior from a user's perspective. Showing one error at a time will annoy users, especially on a lengthy form.

At first it sounds like the first one would be the best, but what about instances where errors cause other errors to occur? Do you just accept the fact that it would happen, and may be slightly confusing for the user?

I'm not 100% certain what you mean, but if you're referring to a rule which turns out invalid which would automatically cancel out another rule, then just don't perform that other rule.

For example, let's say you have an age field, where you only accept an age between 30 - 50.

You'd need three generic tests:
is_integer
is_valid_minimum_value
is_valid_maximum_value

If the is_integer test fails (eg, User enters letters) then there's no point in performing the other two tests:

if (!is_integer($_POST['age'])) {
    $_SESSION['errors'][] = 'Age is not a valid number';
    $numeric_validation_failed = true;
}

if (!isset($numeric_validation_failed)) {
    if (!is_valid_minumum_value($_POST['age'], 30)) {
        $_SESSION['errors'][] = 'Minimum age is ' . $min_age;
    }
    if (!is_valid_maximum_value($_POST['age'], 50)) {
        $_SESSION['errors'][] = 'Maximum age is ' . $max_age;
    }
} 

Of course you could wrap the three function above into a single function if you preferred.

It's the same with a login form. If the username or password is invalid (format-wise), then there's no point attempting to check the credentials against a database. Once the username and password are properly formatted, then you try to login the user. If there's a mis-match, then you have to populate the $_SESSION['errors'] var again with a 'failed login' message, and redirect the user back to the form.

My only question with this is, what is the spead like with sessions. Seeing you could be using a numerise amounts of them.

I've never really thought about this. I suppose if you're concerned about making numerous calls to $_SESSION['errors'] and $_SESSION['formvars'] during a validation routine, then you could just store them in temporary vars ($tmp_errors & $tmp_formvars), then copy them once to their respective $_SESSION vars if necessary.

[EscapeYourMind]

In my opinion that is how it should be done, seeing they are all different types of errors, and exception and trigger errors are at a higher level so you would want to handle them differently.

I kind of felt the same way; there are different types of error handling which work best for certain types of errors. Even if you choose to use exceptions over trigger error, it may still be worthwhile to use a custom trigger_error handler just to post messages to a log file, and let the exception handle its business of trying to deal with the problem and if need be, have the application bow out gracefully.

You can simply display just the first error for a given field; less confusing then having them all, but more informative than just one, as you really want to avoid having the user fix errors one by one, reloading the page each time.

That's how it's typically done, because it's expected behavior from a user's perspective. Showing one error at a time will annoy users, especially on a lengthy form.

So it kind of looks like it may be a pick your own poison situation. I can sort of see the pros/cons for both ways; guess it’s just a matter of picking which one I feel would work best.

I don't see how it would make a difference. The $_POST values are temporary and will be forgotten once you transfer the user back to the form to correct the errors. Wrapping it in a request object still won't make it persist across page requests. That's why you hold the form vars in a $_SESSION for later usage.

Looking back on it, I'm not exactly sure as to what I was thinking. But even if I use a request object, it would be the same as just doing $_SESSION['username'] = $_POST['username'], but instead I would be doing $_SESSION['username'] = $request->get('username').

I'm not 100% certain what you mean, but if you're referring to a rule which turns out invalid which would automatically cancel out another rule, then just don't perform that other rule.

Well, for example: If there’s a required field on the forum, and you also want to do another validation, like say it must contain a number. Obviously if you don’t enter anything, the first rule will fail, and because of that the second rule would also. But if you display both errors to the end user, they may get confused when they try to fill it in. Obviously it’s not the best example but I'm just trying to illustrate the potential waterfall effect with the errors. Upon writing this, it also seems that if all errors are display they could almost act as a reinforcement of the rules that are applied to that particular field; yet may still be overwhelming to the user.

With your example, while it may work nicely there, I'm not so sure It would work as nicely in my system. I'm using an InputProcessor in which you load rules into it, and each rule can work on multiple form fields when its run, so it would be kind of hard to do it that way since there is no cascade of errors on a single field at a time. It basically runs a rule on all fields, and then moves on to the next rule. Obviously with some problem solving it would be possible, but if I just display all errors, it wouldn’t be necessary.

My only question with this is, what is the spead like with sessions. Seeing you could be using a numerise amounts of them.

I was kind of wondering the same thing about the additional overhead incurred vs. a method like I used to use in which when a form error was found, it would just basically stop and print out the error page. Not at all user friendly, but I also don’t have to worry about holding large form values in sessions and the additional overhead from a file or database read/write depending on session storage method.

[champ]

I'm using an InputProcessor in which you load rules into it, and each rule can work on multiple form fields when its run, so it would be kind of hard to do it that way since there is no cascade of errors on a single field at a time.

Alternatively, you could feed your validation routine the $_POST array and an array of $rules, which does cascade the errors on a per-field basis.

$rules = array(
    'username' => array(
        'name'        => 'username',
        'label'       => 'Your Username',
        'maxlength'   => 10,
        'is_required' => true,
        'is_username' => true
    ),
    'password' => array(
        'name'        => 'password',
        'label'       => 'Your Password',
        'maxlength'   => 10,
        'is_required' => true,
        'is_password' => true
    )
); 

Your validator could loop through the rules array to see if it finds a matching $_POST var. If it does it checks to see if it is really set (eg, not just spaces, tabs, new lines), and, if so, performs a suite of validation checks relevant to that particular form field back-to-back:

function validate($_POST, $rules)
{
    $errors = array();
    foreach ($rules as $key => $rule) {
        if (is_really_set($_POST[$key])) {
            // do validation
            if (!empty($rule['is_username'])) {
                if (!is_valid_username($_POST[$key])) {
                    $errors[$key][] = $rule['label'] . ' is not
                    a valid username';
                }
            }
            if (!empty($rule['is_password'])) {
                if (!is_valid_password($_POST[$key])) {
                    $errors[$key][] = $rule['label'] . ' is not
                    a valid password';
                }
            }
            if (!empty($rule['maxlength'])) {
                if (!is_valid_maxlength($_POST[$key],
                    $rule['maxlength'])) {
                    $errors[$key][] = $rule['label'] . ' can not
                    exceed ' . $rule['maxlength'] . ' characters';
                }
            }
        } else {
            // was it actually required
            if (!empty($rule['is_required'])) {
                $errors[$key][] = $rule['label'] . ' is required';
            }
        }
    }
    return $errors;
} 

You could do some other useful things above such as add the $_SESSION['formvars'] array back into the mix.

[kyberfabrikken]

I've never really thought about this. I suppose if you're concerned about making numerous calls to $_SESSION['errors'] and $_SESSION['formvars'] during a validation routine, then you could just store them in temporary vars ($tmp_errors & $tmp_formvars), then copy them once to their respective $_SESSION vars if necessary.

The session isn't persisted until the end of the processing, so that makes no difference. The size may have something to say, but as long as we're talking a few formfields, it has no relevance.

[Dr Livingston]

> The size may have something to say, but as long as we're talking a few formfields, it
> has no relevance.

It isn't the number of form fields that you should be concerned about, as such, but the actual content, and the size of that content in real terms if you store FORMs submitted data in SESSION, for the purpose of reinitialising those form fields in the event of an error

But in my mind, using SESSION in this way is pollution...

[EscapeYourMind]

I sort of feel the same way. On one side the forms I need it for will be storing large amounts of data. However this is all based in the admin portion of the site, so I dont think it would have a significant impact on the system since obviously the admin doesnt get hit anywhere near as often as the main site. In saying that though, Dr. Livingston, how would you keep the form fields filled in after a redirect back to the form because of errors?

[Xenon_54]

Hi,

I'm very interested by your discussions. But as you have probably see, there is no answer for the moment on this topic that has filled my expectations.

I know that you don't really like this website at SitePoint but, anyways, Dig* is one website that has interested me by the way they are handling forms. This is clean and seems to be working well on client-side.

But for now, how they are handling on server-side, I have no clue at all. Anybody has an idea?

Regards,

[danh2000]

Sorry to highjack this thread, but... rather than start a similar one, I thought I'd post here.

I'm just delving into OO and have a few questions with regards to error handling.

I'll start by explaining how I'm coding my current app (wrongly or rightly)..

My page code creates a Controller, based on the 'action' this could create a UserAdminObject (for instance) which would create a UserDAO object that performs a query and returns data back upto my UserAdminObject.

In my Data Access objects I'm suppressing mysql errors and am throwing an EnvException (environmental exception) if the db could not be connected to or a query could not be performed etc.. I keep throwing this all the way up through the classes that use my DAO objects and am catching this at the top (controller) level of my app - the site cannot work without the database, so I log and report the error and inform the user that the site is currently down.

This part seems to work well..

My question is about the other types of errors that could occur and where to deal with them.. I sort of see things as Environmental Errors, Application Errors (someone is using the classes incorrectly) and User Errors (mandatory fields not being populated etc..)

Where would I best deal with these scenarios?

Should every class validate that required vars were passed and that they were passed as the correct type (should I consider type hinting here?) and generate Application errors if the class is being used incorrectly..

..or would I rely on classes further up the chain (controller for instance) to validate vars before using the objects lower down the chain and generate user errors here?

Should I be checking at the lowest level (and every level) and keep throwing the errors up the chain to be dealt with by the controller?

I hope I making sense here..?

Any advice would be much appreciated.

Thanks, Dan.

[CrucialWebHost]

It really depends on the site I guess. Sometimes I'll use Javascript/AJAX to display the errors without refreshing (or processing the form). Other times, I'll let the form process, and then show the error (by either saying what the error is, or by highlighting what needs to be fixed and notifying the user), but still show the form and keep their other information in the fields. And on some of my sites, I actually have an alert box display that lets the user know what they are missing.

Your best bet is to highlight fields initially and let them know what is and is not required.

Then of course run some error checking to make sure things like their email address or phone number is correct.