In an attempt to display more meaningful and localized error messages when an exception occurs during parsing a template in the VelocityServlet, I would like to use the exception information as model data for an error/troubleshooting view.
For parsing exceptions, it looks like I would have to parse the text message from the exception to get the information (line/column position, token encounter, list of tokens expected, etc.). For example, I would like to display the template source lines surrounding the line and column where the parsing error occurred to assist the template designer in diagnosing the problem and possibly suggesting solutions. I would also like to display the problem in a more localized format, if possible. It looks like the ParseErrorException contains only the message from the ParseException thrown by processing a template. On the other hand, the ParseException contains much of the detail information that could be easily be used as model data to display in the error/troubleshooting view(s). An idea: Would it be possible to enhance the ParseErrorException to encapsulate the ParseException (or information from it) and provide methods to get to the information it holds? Or simpler, just have it provide a method to get the ParseException? It looks like the ParseException has the data but it would need to have getters to get the data from the public fields (or are public fields accessible via Velocity?) Of course, the ParseErrorException is also thrown when the input encoding is not valid (UnsupportedEncodingException) so this makes it more complex to distinguish what kind of exception is encapsulated. Well...just an idea. I hope this makes sense. What do you think? Can you suggest an alternative to parsing the exception error message? bill -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
