Difference between revisions of "Corona Exceptions"

Latest revision as of 04:43, 27 October 2006

Exception Handling in Corona

General Guidelines

Some general guidelines concerning throwing and catching of exceptions are:

1. don't catch an exception if you can't handle it
2. don't define null handlers
3. don't swallow exceptions (log and ignore, log and return null, etc.), unless explicitly specified in javadoc
4. don't define a general throws Exception clause
5. don't define a general catch Exception clause
6. don't throw exceptions from finally block
7. don't use exceptions for control flow

More descriptive guidelines can be found here:

Tips

Guidelines

Antipatterns

Wrapping

Exception wrapping is used for inter-tier propagation. Exceptions thrown by another architectural layer are caught and rethrow as an exception from the current architectural layer. The original exception will be nested in the new one.

Each method throws only exceptions that indicate what went wrong in its operations, not where.

??? All system / java exceptions are caught and wrapped into a Corona exception.

Logging

Exceptions will be logged once only in the catch block that handles an exception. The log level is either ERROR, WARN or INFO depending on the exception. INFO indicates interface (caller) exceptions. WARN and ERROR indicates system (application, subsystem) exceptions.

??? The creation of Corona exceptions will be logged by exception constructor. If an exception is rethrown, its caught is not logged.

Corona exception hierarchy

The basic hierarchy of Corona exception is as follows:
CoronaException - top level exception class, extends Exception. Subclasses:

• CoronaInterfaceException - thrown if a method detects that an input value does not conform input requirements, example: NullUriException.
• CoronaSystemException - thrown if a method can not provide an operation due to an error in the method or in a subsystem. Subclasses:
  • CoronaResourceException - a resource can not be manipulated correctly, examples:
    • ContainerException - an operation on container failed
    • RepositoryException - an operation on repository failed, example: NoTeamRepositoryException)
  • CoronaInfractructueException - a configuration or subsystem exception, example:
    • ServiceException - a required service/adapter/factory can not be found or invoked, example: NoRepositoryAdapterFactory
  • CoronaRemoteException - an error occurred during communication
  • CoronaEventException - a local event can not be created or manipulated
• CoronaDomainException - thrown if an error is detected in Corona business logic, example: NoSuchContainerException - thrown if a method requests opening a non-existing container.
• ConfigurationException (abstract) - corona configuration cannot be read correctly, examples:
  • ConfigurationDirectoryException - specified configuration directory is incorrect.
  • ConfigurationServiceException - Configuration service was not started.

All generic Corona...Exceptions are abstract so they are not thrown.

Only subclasses of Corona...Exception can be created and thrown. The word "Corona" is not added to concrete exceptions. Catch blocks should be created for each type of Corona exception that can be thrown by a method.

Detailed Issues

Return Values

Methods should limit the number of different exception classes to throw.

A method that is allowed to return regular null should should specify in javadoc the fact. The invoker is expected to check for null value.

CoronaSystemExceptions should be caught / handled as soon as possible. ??? They can be swallowed in some cases.

CoronaInterfaceExceptions and CoronaBusinessExceptions must be propagated (with or without wrapping) to the caller. In particular an error message is displayed if the operation concerns user interaction.

NullObject pattern can be used after catching or detecting a CoronaSystemExceptions - if there is an error is the application, its configuration or a subsystem. For example, null object is returned if no Corona log service reference if found.

Error messages

Corona exception defines getErrorMessage method. XXXException.getErrorMessage returns error message depending exception. The message is constructed from a template and exception data. plugin.properties contains an error message template for an exception class.

??? The package org.eclipse.corona.tools.ui supplies a helper class that displays an error dialog.

Remote invocations

TODO:

??? Should client know all kinds of exceptions that occur on the server? It is necessary if wrapping on server side is used.

Web services

TODO:

SOAP fault part packs exceptions and stack trace.

ECF

TODO: