Could you add what additional information
each exception must contain beyond its base exception?
- 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.
Glenn
From: corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Kaczmarek,
Pawel
Sent: Thursday, October 05, 2006
7:06 AM
To: Corona
development
Subject: RE: [corona-dev]
Exceptions in Corona.
I've added a wiki page on exception
handling. It contains general guidelines, some detailed solutions and Corona exception
hierarchy.
http://wiki.eclipse.org/index.php/Corona_Exceptions
Points marked as "???" are
proposals that need to be accepted or rejected.
The last point "Remote
invocations" is still under development.
Pawel
From: corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Hawkins,
Joel
Sent: Wednesday, October 04, 2006
2:32 PM
To: Corona
development
Subject: RE: [corona-dev]
Exceptions in Corona.
A good rule
of thumb is that each remote method on a logically defined tier should declare
that it throws just one exception (in addition to RemoteException): a nesting
exception that nests any of the exceptions that could be thrown within that
method's implementation. To reiterate a thought expressed earlier, this
methodology plays perfectly into interface-driven architecture: the
implementation-specific exceptions are abstracted into a singly defined
exception for some interface method.
I think this is the kind of stuff we need right now
– a set of exception handling principles to adhere to going forward.
I’d like to see us not stop everything to go revisit our exception
handling at this point – I’d prefer to focus on functionality.
Perhaps we can do a wholesale exception cleanup at the start of one of our
upcoming milestones.
Pawel, this is your area of expertise. Could you
provide us with a set of recommendations? Then we can discuss as a group how to
apply these across our architecture.
Thanks,
Joel
=00The 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.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.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.