A wise old hermit known only as Aslak Helles?y 
<[EMAIL PROTECTED]> once said:

>       Translator.java 
> Log Message:
> Instead of throwing an XDocletException when a resource is not found, 
> do cat.error().
> IMO the getString() methods should never throw any Exceptions. What if 
> you do a
> new SomeException( Translator.getString( "blabla" ) ); and that bombs?

Then an XDocletException gets thrown, and the Ant script output tells us 
the resource is missing.  Of course, that meant I had to throw/catch extra 
XDocletExceptions in various places, and ended up finding those 
BuildExceptions where they shouldn't have been :-)

Originally, I just had it return the resource key if it didn't find a 
match, but figured it was better to stop the build than have it putting 
some cryptic text in generated code instead of the expected message (I'd 
planned from the start to let templates use it too).  And of course our 
code is all perfect, so it's only people's custom bundles, templates & 
subtasks that it will affect ;-)

Having said that, I guess even within generated code it's only ever going 
to be comments/descriptions etc. that get translated (the closest it 
currently gets to touching code is the EJB entity_dataholder_key string), 
which shouldn't prevent compilation/deploying.  So it's probably okay to 
let it carry on; it wants to return a more explanatory string than "GRR", 
though.

What does anyone else think?  Stop the build (i.e. throw exception) and so 
force you to go fix the mistyped resource key in the template/code, or let 
it carry on?

> Andrew, care to modify this to do cat.error instead (all over the 
> class?)

All over?  The rest of the logging is just trace code (so I could check 
what exactly it was trying to look up, and why it was failing to find 
bundles I thought were there).  The only one that might not be 
considered such is the "bundle not found" one at the end, but that'll get 
logged by the cat.error you added as soon as it throws the 
MissingResourceException back to getString().


Andrew.

_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel

Reply via email to