Hi, Our company have been using Velocity for a while, and I believe there is much room to improve in terms of exception declaration in the Velocity API. Reasons are summarized below.
To the caller, a method that throws Exception is equivalent to throwing any possible type of checked exception plus runtime exception. Examples: Velocity.getTemplate() and Template.merge(). Such method signatures are almost meaningless to the caller besides saying there can be exception thrown (which is always the case anyway). The only thing such method signature (which throw the generic Exception object) does is to "force" the caller to either catching the Exception, or declaring the "Exception" in the method again so the caller code will compile. A better approach is to avoid declaring the generic "Exception" in method signature, and either to throw 1)a specific set of checked exceptions for "application type" exceptions, or 2)runtime exceptions for "system type" exception. The advantages are that for (1), the caller can expect and handle a specific limited set of exceptions and for (2), the caller can choose to either handle such system exception locally, or just ignore them and let them bubble up the method invocation chain without the need to declaring them in the method signature. Even a simple strategy of modifying all existing methods that already throw the Exception object to instead throwing a RuntimeException object will immediately offer the benefits of simplifying the API, and allow almost full backward compatibility at both source and binary level. I am currently a committer to the jakarta JCS project, and wish to also become a committer of the Velocity project so I can make such improvement to the velocity API. Please vote me in. Thanks, Hanson
