Difference between revisions of "Java Exception Handling"
Jump to navigation
Jump to search
| Line 52: | Line 52: | ||
== Conclusion == | == Conclusion == | ||
=== Distinguish between errors | === Distinguish between repairable exceptions and errors === | ||
=== Prefer unchecked exceptions inside a module === | |||
=== Only catch repairable exceptions === | |||
=== Inside a module, always throw errors up as they are === | === Inside a module, always throw errors up as they are === | ||
Revision as of 09:18, 3 November 2008
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