Difference between revisions of "Java Exception Handling"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 1: Line 1:
== Problem description ==
== Problem description ==
=== Modules need dependencies of other modules only because of their exception classes ===
=== Modules need dependencies of other modules only because of their exception classes ===
From validation/ItemValidating:
<code>
    String validateItemXml(final String itemXml) throws
            ValidationSchemaNotFoundException,
            TechnicalException;
</code>
From importmanager/ImportHandler:
<code>
    byte[] doFetch(String sourceName, String identifier) throws FileNotFoundException,
            IdentifierNotRecognisedException,
            SourceNotAvailableException,
            TechnicalException,
            FormatNotRecognizedException;
</code>


=== Stacktraces are sometimes swallowed ===
=== Stacktraces are sometimes swallowed ===

Revision as of 08:55, 3 November 2008

Problem description

Modules need dependencies of other modules only because of their exception classes

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

Sometimes, excessive stacktraces are shown, even without useful information

Logger.error, System.out and e.printStackTrace are mixed up happily

No distinction between exceptions and errors

Conclusion

Distinguish between errors and exceptions

Inside a module, always throw errors up as they are

When catching exceptions, log appropriately

Between modules, throw only generic exceptions (e.g. java.lang.Exception, java.lang.RuntimeException) without cause