Post by Daniel DekanyPost by Jonathan RevuskyTemplateLoader object from the Configuration,
Post by Jonathan RevuskyPost by Leandro Saadand
Post by Jonathan RevuskyI *think* that will just return null if the template is not available.
Though I don't remember so well honestly.
OTOH, I'm not sure what the big deal about the exception getting
thrown
performance.
That's the reason (the only one) that occurred to me also. But I can't
imagine scenarios where this would be significant.
it is for my unit tests and large scale generation from a UI ;)
Anyway as another poster stated, relying on exceptions for controlling flow
is bad style. Providing a method to check if something will
be available to avoid the overhead in code and runtime is in my book A
Good Thing.
If you look into the API docs, TemplateLoader.findTemplateSource
doesn't throw exception if the template is missing, but it return
null. This behavior is very clearly required by the API. The same goes
for TemplateCache.getTemplate(). Unless there are bugs around, it
should not throw exception if the template is missing.
Yes, but the top-level API method, Configuration.getTemplate() throws an
exception if these lower-level methods return null.
But this is the correct semantics IMO for the top-level public API that
most people will use. In typical usages of FreeMarker, I don't think
that a template fails to load. Or, I mean, rather, that if loading a
template does fail, it's indicative of an extremely critical problem in
your app and you have little recourse but just to abort or shut down.
Really, a FreeMarker template is application *code*. In fact, I would
imagine that many, if not most, deployed apps would load FTL files via
the same ClassLoader mechanism that is used to load a .class file.
Certainly, if an app fails to load a class it needs, this is a severe
error that causes an exception, actually a java.lang.Error, I guess.
Now, you still can, for special situations, check whether a class is
avaialble to be loaded, but the way you do that would be precisely
analogous to what I proposed for isTemplateThere().
boolean isClassThere(String className) {
try {
Class.forName(className);
} catch (Exception e) {
return false;
}
return true;
}
Post by Daniel DekanyRegarding the checking function VS exception topic... sure, doing it
with exceptions is ugly. However, relying on a separate checker call
and a separate getter call is not necessary better. First of all, the
atomicity of the operation is lost then. I mean, just because at the
time of checker call the template was present, what ensures that it
will be still there when later you call the getter method? Some short
of transactional storage is needed to ensure thing like this, which
probably means a lot of overhead if we are talking about performance.
Also, if some errors hazards are OK (that the user of API must
realize), then calling the checking and the getting method may means
more I/O operations, as you access the file twice. So usually the good
solution no checker method, but getter method must indicate if the
resource is missing in its return value, or maybe by throwing an
exception.
The way our top-level API works currently seems right to me. You can get
at the underlying TemplateLoader object via
Configuration.getTemplateLoader() and then the underlying TemplateLoader
will return null rather than throw an exception. But I am pretty sure
this is a special case usage.
If somebody writes:
template = config.getTemplate("purchase_form.ftl");
and the template can't be found, this is almost always going to be a
severe error condition and is not part of normal flow of execution. It's
the same as if a class fails to load. It means that some .jar file that
is suppsoed to be present is not there or whatever, which is a pretty
severe problem.
JR