Ever wondered if there was a way to stop Zope from barfing error messages all over your screen when one of your scripts crashes and burns? Well, guess what - there is! Meet the and tags, which can be used to trap and resolve errors in script execution.
Now, since I've been talking so much about errors, how about introducing you to one? Take a look at the following code, which deliberately introduces an exception in a DTML script,
and then take a look at the output, which might awaken some unpleasant memories.
Before you start screaming, you should know that this is one of the more common errors Zope developers see. It's ugly, it's loud, it'll really spoil your morning, but it can be fixed fairly easily. I'll be showing you how shortly, but first, let's dissect this baby a little.
In the example above, Zope tries to access the value of the variable "CheckThisOut". Now, this variable does not exist in the Zope variable namespace. What does Zope do? Rather than quietly packing up and moving to a new neighbourhood, Zope decides to generate a KeyError exception. You can see this from the first few lines of the output, which describe the exception, together with the variable that caused it.
Zope has encountered an error while publishing this resource.Error Type: KeyErrorError Value: CheckThisOut
There are also a couple of useful suggestions as to why the error might have occurred:
* This resource may be trying to reference a nonexistent object orvariable CheckThisOut. * The URL may be incorrect. * The parameters passed to this resource may be incorrect. * A resource that this resource relies on may be encountering an error.
From the above suggestions, it's pretty clear that Zope's analysis is not totally incorrect - the error occurred because the "CheckThisOut" variable doesn't exist. And Zope also provides a "traceback" of the error, which gives developers with detailed debugging information on the steps that led to the error. A little analysis of this traceback data, and you'll quickly be able to identify the scripts involved in the error (this feature is particularly useful when dealing with complex errors that you can't locate in the first code pass-through).