VoiceXML 2.1 Exceptions

error.badfetch -- FATAL ERROR

This is a somewhat standard error that we should always handle in our scripts. The 'error.badfetch' will not only get thrown upon a URL/URI timeout or server problem, but error.badfetch will also get thrown if we have a nonspecific grammar error, a document parse error, or if a security violation occurs. Also note that a malformed URL/URI for an audio file will not force the interpreter to throw this error; it will simply look for nested TTS within the audio tag to play, else it will simply move along as dictated by the form interpretation algorithm.

Per the w3c specification, we can drill down even further and write a <catch> handler for each specific type of badfetch that returns a HTTP response code. As such, any 'error.badfetch' handler that has a specific HTTP response code suffix, (see RFC2616 for a listing of all response codes), can be handled appropriately. For instance:


<catch event="error.badfetch.http.404">
 <log expr=" '*** CAUGHT AN ERROR.BADFETCH.404 ***' "/>
</catch>

<catch event="error.badfetch.http.500">
 <log expr=" '*** CAUGHT AN ERROR.BADFETCH.500 ***' "/>
</catch>

<catch event="error.badfetch.http.505">
 <log expr=" '*** CAUGHT AN ERROR.BADFETCH.505 ***' "/>
</catch>

See the 'debugging' documentation, and the w3c specification for further information on catching and handling these types of exceptions.

error.semantic -- FATAL ERROR

The error.semantic condition usually indicates a coding error in the VoiceXML file itself, possibly caused by an invalid <property> value, an undefined variable is referenced, or any number of standard run-time errors in the script. When this is encountered, you will likely need to comb over your code to the minute detail in order to find the culprit. Experienced coders will make liberal use of the <log> element in order to track variables and more easily narrow down what is at fault, and will also put in some heavy analysis of the Voxeo debugger output.

error.unsupported.format -- FATAL ERROR

The 'error.unsupported.format' condition is thrown when the interpreter encounters a grammar that contains non-GSL/grXML type grammar content, or if it enconters an audio file that is the interpreter is not able to convert and output. Chances are, you will never need to have this handler within your code at all.

error.maxspeechtimeout -- NONFATAL ERROR

This somewhat rare event only occurs if you have a caller that exceeds the platform-level 'maxspeechtimeout' property; this being 30 seconds of uninterrupted speech for a single recognition field. It's unlikely that any sane person would write a grammar file that could actually recognize 30 seconds of speech, but in the event that you are doing your coding from Bellevue Mental Hospital, then you may want to add this handler.

ANNOTATIONS: EXISTING POSTS

0 posts - click the button below to add a note to this page

General Exceptions and Error Types

| TOC

| Shorthand Exceptions