Java Exception Handling
Revision as of 09:47, 3 November 2008 by MFranke (talk | contribs) (→When catching exceptions, log appropriately)
Problem description[edit]
Modules need dependencies of other modules only because of their exception classes[edit]
From validation/ItemValidating:
String validateItemXml(final String itemXml) throws
ValidationSchemaNotFoundException,
TechnicalException;
From importmanager/ImportHandler:
byte[] doFetch(String sourceName, String identifier) throws FileNotFoundException,
IdentifierNotRecognisedException,
SourceNotAvailableException,
TechnicalException,
FormatNotRecognizedException;
Stacktraces are sometimes swallowed[edit]
try
{
...
}
catch (MalformedURLException e)
{LOGGER.error("Error when replacing regex in fetching URL"); e.printStackTrace(); }
catch(UnsupportedEncodingException e)
{e.printStackTrace();}
try
{
...
}
catch (JiBXException e)
{
e.getCause();
}
Sometimes, excessive stacktraces are shown, even without useful information[edit]
Example from coreservices: File:Exception1.txt
Logger.error, System.out and e.printStackTrace are mixed up happily[edit]
see above
No distinction between exceptions and errors/checked and unchecked exceptions[edit]
Conclusion[edit]
Distinguish between repairable exceptions and errors[edit]
Prefer unchecked exceptions inside a module[edit]
Only catch repairable exceptions[edit]
Inside a module, always throw errors up as they are[edit]
When catching exceptions, log appropriately[edit]
Do not throw self-defined exceptions without a surplus[edit]
Between modules, throw only generic exceptions[edit]
e.g. IllegalArgumentException, IllegalStateException, RuntimeException