CSCI 6962: Server-side Design and Programming

1. CSCI 6962: Server-side Design and Programming Error Handling and Informative Error Pages

2. Form Validation • Detecting user error • Invalid form information • Inconsistencies of forms to other entities • Enter ID not in database, etc. • Correcting user error • Providing information or how to correct error • Reducing user memory load • Preventing user error • Good instructions • Field types/values that prevent error • Error tolerance • Example: Accepting phone numbers in multiple formats

3. Error Pages • Put error message next to source of error • Allows user to see where correction is needed

4. Adding Error Messages to Pages • Generating messages in bean (old school JSP idea) • Error messages member variable of bean • Output field linked to that value • Using built-in validators in JSF page • Required fields • Range validation • Regular expression • Custom validator beans • Still in beta stage

5. Bean Generated Messages • Each form element has corresponding outputLabel for error message • outputLabel linked to member variable in bean • Initially empty string so no message visible at first

6. Bean Generated Messages • Member variable changed to appropriate error message if that value is invalid

7. Built-in Validators • Required validators • Attribute in most JSF form tags • Should specify a corresponding requiredMessage to be displayed if field not present • Error message displayed at bottom of form by default

8. Built-in Validators • Associate error message to <h:message tag • Give the field an id attribute • Place <h:message tag at desired location next to field • Give it a corresponding from attribute to link to id

9. Other Built-in Validators • Format: • <h:inputText id=“id” validatorMessage=“message”> <f:validateSomethingattributes></h:inputText> Message displayed if invalid Type of validation done

10. Other Built-in Validators • Tags: • <f:validateLongRange/>Validates value is integer • <f:validateDoubleRange/>Validates value is a number • <f:validateLength/>Validates string length between limits • <f:validateRegex/>Validates against regular expression • <f:validateRequired/>Can use in place of required attribute

11. Numeric Validators • Can also set minimum and/or maximumlegal values: Error message diplayed Fails if not integer Fails if < 1

12. Regular Expression Validators • Specify pattern attribute to match:

13. Limits of Built-in Validators • Limited abilities • Required validator does not automatically trim, etc. • Limited error message capability • Can only display single error message (other than required message) even if multiple validators used • Cannot combine with form-based validation • Page-based validation done first • If fails, action method of command element not called • Advantage: Web designer controls error messages • Possibly better understanding of user

14. Custom Validators • Can create own validators for cases not covered by built-in validators • Specific support class for each form (implements Validator interface) • Throws ValidatorExecption containing error message • Handled by <f:validator tag • Main limit: Can only detect problems in single form element it is associated with • Cannot validate credit card expiration, for example

15. Custom Validators • Separate class (no easy way to create in NetBeans) Required libraries to import ID for access by JSF pages Has validate method with these parameters (called by JSF page) Implements Validator interface

16. Custom Validators Value entered into field extracted from valueparamter Must convert it into a String to access it Do validation and set error message

17. Custom Validators If not valid, construct a FacesMessage object from error message Throw back to JSF page, where it will be displayed in message tag associated with form element

18. Custom Validators Validator tag linked to validator class • When page sumitted, validate method of QuantityValidator called • If ValidatorException thrown, its message displayed

19. Last Resort Error Handling • User should never see Tomcat-generated error page! • Reduces confidence in your entire site • Confuses user (did they do something wrong?)

20. Last Resort Error Handling • “Last Resort” error page called if unhandled error • Identifiable company logo and designso the user can be sure that they are still on your site • Main navigation bar which offers user a way to try something else • A reassuring message telling this is not user’s fault • A link to email the webmaster to inform them of the problem • Note: may need to be >512 chars to fool IE

21. Default Error Pages • Can specify default page for: • Unhandled exceptions(such as NumberFormatExceptions) • Missing pages and other server-related errors • Done in web.xml file • Error pages under pages tab

22. Default Exception Handling • Specify page to jump to and type of exception • Must use full name of class (including library.package.classname) • Can use base classjava.lang.Exceptionto catch everything • If this type of exception occurs and is not handled inside a try/catch, jump to this page

23. Handling Missing Pages • Unavoidable in complex web sites with multiple developers • Causes error code 404 • If this error code occurs within, jump to this page