[corona-dev] Exception handling in Corona

["Kaczmarek, Pawel" <Pawel.Kaczmarek@xxxxxxxxxxxxxxxx>]

Initial ideas about exceptions

 

(You can read it after EclipseWorld, nothing urgent.)

 

Exception hierarchy

 

The main exception class is CoronaException (already exists). I suggest that class constructors use logging system to log the exception when it is created. Main subclasses define getSeverity() method to determine the severity of an exception (DEBUG, ERROR, WARNING, INFO ...)

 

I suggest the following subclasses for CoronaException:

• CoronaSystemException - thrown if, for some reason, a method can not provide the expected operation. Subclasses:
• CoronaServiceException - 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
• CoronaResourceException - a resource can not be manipulated correctly. Subclasses:
• ContainerException - an operation on container failed
• RepositoryException - an operation on repository failed
  (example: NoTeamRepositoryException)
• CoronaPreconditionException - thrown if a method detects that input value does not conform input requirements.
  (example: NullUriException)

Other Corona exceptions inherit from basic classes. The word "Corona" is not added to new exceptions.

What do you think about it?

 

Corona specific assumptions

·        Exception propagation

A typical scenario for a Corona exception is:

 1. Eclipse subsystem throws an exception (for example CVSException).

 2. The exception is caught and wrapped to a Corona exception: new OurNewException(originalException). Only Corona exceptions are thrown from Corona methods. The originalException can be accessed by e.getCause().

 3. Corona exception is caught by a caller and exception handling is applied: logging, error message display or an alternative operation.

 

·        If a method is allowed to return null, it does. However, if a method is not allowed to return null, it should throw an exception.

For example a repository adapter might be null, but adapter factory should not. A method that returns a repository factory should throw an exception instead of returning null. Exceptions are not used for normal control flow.

 

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

Only subclasses of Corona...Exception can be created and thrown. catch blocks should be created for each type of Corona exception that can be thrown by a method.

 

·        ContainerManager will be an important exception handling point as it deals with remote communication.

 

·        Exceptions are logged automatically when thrown.

They need to be logged when caught. It will be useful in tracing client-server communication.

 

 

Error messages

Currently, we have no coherent strategy for displaying error messages. I suggest adding a class to corona.ui.tools that can display an error message or a question dialog.

 

 

Asynchronous executions / remote calls

Remember that it is generally not possible to throw an exception from a thread (Eclipse Job).

 

An idea for the future.

We might think of registering a listener for exceptions and other errors. If an exception is created, it sends an event indicating exception type, message and so on. The code can be placed in generic CoronaException class. The listener concerns both client and server-side problems. Client sends exception messages to server.

 

Comments are welcomed.

 

Pawel

 

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.