| To recapitulate what's this entry is about: FreeMarker by default treats an attempt to access a non-existent variable or a null value (this two is the same for FreeMarker) as error, which aborts the template execution. First of all, you should understand the reason of being picky. Most scripting languages and template languages are rather forgiving with missing variables (and with null-s), and they usually treat them as empty string and/or 0 and/or logical false. This behavior has several problems: It potentially hiders accidental mistakes, like a typo in a variable name, or when the template author refers to a variable that the programmer doesn't put into the data model, or for which the programmer uses a different name. Human is prone to do such accidental mistakes, computers are not, so missing this opportunity that the template engine can show these errors is a bad business. Even if you very carefully check the output of the templates during development, it is easy to look over mistakes like <#if hasDetp>print dept here...</#if>, which would then silently never print the dept of the visitor, since you have mistyped the variable name (it should be hasDept). Also think about maintenance, when you later modify your application... most probably you will not re-check templates that carefully each time. Makes dangerous assumptions. The script language or template engine knows nothing about the application domain, so when it decides the value of something it don't know to be 0/false, it is a quite irresponsible and arbitrary thing. Just because it is not know what's your current bank account balance, can we just say it is $0 (and how easy it is to accidentally write Balance: ${balanace})? Just because it is not known if a patient has penicillin allergy, we can just say he/she doesn't have (and how easy it is to accidentally write <#if hasPenicilinAllergy>Warning...<#else>Allow...</#if>; there is a typo in this, if you didn't see)? Just consider the implications of such mistakes for a moment. They can be quite severe and troubling. Showing an error page is often better than showing incorrect information that formally looks good.
Being not picky is mostly sweeping under the carpet in this case (not facing with the problems), which of course most people feels more convenient, but still... we believe that in most cases being strict will save your time and increase your software quality in the long run. On the other hand, we recognize that there are cases where you don't want FreeMarker to be that picky with good reason, and there is solution for them: It's often normal that your data model contains null-s or have optional variables. In such cases use these operators. If you use them too often, try to rethink your data model, because depending on them too much is not just results in awkward verbose templates, but increases the probability of hiding errors and printing arbitrary incorrect output (for the reasons described earlier). On a production server you may rather want to show an incomplete/damaged page than an error page. In this case you can use other error handler than the default. Error handlers can be made that rather skip the problematic part than abort the whole page rendering. Note, however, that although the error handlers don't give arbitrary default values to variables, for pages that show critical information it's maybe still better to show an error page. (Another feature you may interested in: the attempt/recover directives)
|