これは、JSP の典型的かつ根本的な設計の問題です。 JSP を使うとき、いったい何種類のエラーに遭遇するでしょうか? 例えば、JSP Servlet が、.jsp テキストファイルから自動生成されて、 コンパイラでコンパイルされ、生成/解析エラーやコンパイルエラーが 起こるとどうなるでしょうか? JSP が不必要に複雑なために、 エラーのパターンが実際に非常に多くなっているのです！
この問題の中で最も美しくないのは、エラーが 2つの異なる仕組みを通して報告される点です。 パーサは独自の種類のエラーを投げますし、javac コンパイラもまた別の種類のエラーを 投げます。そして、生成処理の結果として起こる、コンパイラからのエラーは多くの場合、 まったく意味不明です。例えば、このエラーがどこで起こったか、説明できますか？
エラーの原因が最初の out.println() の後に;が抜けていたせいだとわかった
あなたは正解です! さて、Java のコードを書いたことも見たこともない人の立場に
立ってみましょう。そういう人がこのエラーを迅速かつ容易に理解できると思いますか?
それに加えて、このエラーの発生した場所が、その原因となった場所とは違う場所だった場合、
元の .jsp ファイルから抽象化したレベルがあり、
さらに生成された中間的な .java ファイルがあるため、
エラーの原因となった場所を見つけるのは困難です。
繰り返しますが、Velocity には、中間ステップも抽象化レイヤもないので、 これと同じ問題で苦しむことはありません、
また、JSP では Throwable な例外がページの処理中に投げられたときに 使用するエラーページを定義できます。これもまた、 MVC モデルを破壊することにならないでしょうか? 言い換えれば、アプリケーションフレームワークが エラーメッセージの扱いに責任を持てないのです。
JSP ページのどこかで Exception を投げるためには、 ステートメントの中に最初にそれを埋め込む必要があります。 この特殊なケースでは、コンパイラで最適化が有効になっている場合、 例外が全てコンパイルされない可能性があることに注意してください。 したがって、[下記の例の]「true」の代わりに、 具体的なオブジェクトを使わなければなりません。 厳密な MVC モデルを使うなら、この方法は現実的には難しいかもしれません。 なぜなら、オブジェクトの生成処理が View を破壊するからです。
その理由は、JSP が Exception の後に追加で out.println("\r\n");
を生成するからです。javac がページをコンパイルしようとするときに、
デバッグしづらい別のエラーが起こります。
(自分ではうまく説明できないので) 直接 Jason の書籍から引用すると
Velocity では、テンプレート内部にどんな Java コードも埋め込むことを 許可していないため、同じ問題は発生しようがありません。 テンプレートで唯一許されるのは Velocity テンプレート言語（VTL）と メソッド呼び出しだけです。
それ以外は全てパーサが「テキスト」と見なしてそのまま出力されます。
Velocity でトラブルが起こるのは、実行中に例外を投げるメソッドを呼び出す時だけです。
例えば、この VTL では $foo という String が定義されており、
その substring() メソッドを呼びだそうとすると、
IndexOutOfBoundsException が投げられるかもしれません。
例外が投げられると、パーサは処理を停止し、 パーサが実行したメソッドで例外が捕捉された時点のスタックツリーに その例外を吐き出します。その時点で、例外は無理なく扱うことができます。 そうです、この例外は、Java の知識のないデザイナにはデバッグが難しいかも知れませんが、 少なくとも限定的な Java の知識があるテンプレートエンジニアならデバッグは簡単なのです。
これは Velocity との組み合わせで Turbine を使う利点の1つです。 というのは Turbine の設計は、一貫性のある方法で例外を取り扱うからです。 また、Velocity に含まれている VelocityServlet を使ってもこれと同じ機能が実現できます。 この Exception には、エラーが発生した .vmファイル内の行番号とカラム番号が含まれています。 JSP のように抽象化を行わないので、エラーの行番号とカラム番号が一致します。 また、例外を投げるツールはパーサだけであり、中間の .java ファイルではなく、実際のテンプレートに関連した場所情報やエラー情報がこの例外には含まれています。 生成された .java コードの結果である、不可解な javac メッセージを デバッグする必要はありません。ただし、商用のアプリケーションサーバの中には、 エラー時に JSP ファイルの行番号をうまく扱うものもあります。
[どちらを選ぶかは] あなたが判断してください。