Exceptions underwent multiple iterations during the framework's development, and new ideas and concepts (such as transient/non-transient) were added.
However, given that a lot of these exceptions, by being a class can have only one parent, it became difficult to evolve the exception handling mechanisms in a consistent way.
Some framework exceptions rely directly on Throwable, others on AxonException, or AxonTransientException, and then there are also RemoteExceptions.
Since reorganizing this hierarchy will most likely introduce breaking changes, it shouldn’t be done in a minor release but rather as part of Axon Framework 5.
A lot of the code assumes all the errors/exceptions that can happen are Throwable, which is fine for most cases but restricts the framework's handling of failing functions as if they were local failures.
AF 4.2 introduced the removal of the Throwable hierarchy at the lowest (message) level, but it would be beneficial to treat all failures as first-class error objects that are not necessarily JVM exceptions.
At least, not treat them as exceptions for as long as we don’t have to.
In addition, the exposed class hierarchy might rely on marker interfaces instead of only classes that extend Throwable.
Hence, we should validate if exception usages are as desired throughout Axon Framework.
For example, the AbstractChildEntityDefinition implementations throw an AxonConfigurationException, while an AggregateModellingException would be better placed.
When picking this up we should probably also have proper documentation and/or some kind of diagram to make sure in the future we use exceptions consistently.
Actions
Decide on a list of Standard AxonExceptions that are generally available for use
Otherwise, create a specific exception
Evaluate current Exception usage - is the correct Exception thrown?
Evaluate which exceptions are transient and non-transient
Description
Exceptions underwent multiple iterations during the framework's development, and new ideas and concepts (such as transient/non-transient) were added. However, given that a lot of these exceptions, by being a class can have only one parent, it became difficult to evolve the exception handling mechanisms in a consistent way. Some framework exceptions rely directly on
Throwable,others onAxonException,orAxonTransientException,and then there are alsoRemoteExceptions.Since reorganizing this hierarchy will most likely introduce breaking changes, it shouldn’t be done in a minor release but rather as part of Axon Framework 5.
A lot of the code assumes all the errors/exceptions that can happen are
Throwable, which is fine for most cases but restricts the framework's handling of failing functions as if they were local failures. AF 4.2 introduced the removal of theThrowablehierarchy at the lowest (message) level, but it would be beneficial to treat all failures as first-class error objects that are not necessarily JVM exceptions. At least, not treat them as exceptions for as long as we don’t have to. In addition, the exposed class hierarchy might rely on marker interfaces instead of only classes that extend Throwable.Hence, we should validate if exception usages are as desired throughout Axon Framework. For example, the
AbstractChildEntityDefinitionimplementations throw anAxonConfigurationException, while anAggregateModellingExceptionwould be better placed.When picking this up we should probably also have proper documentation and/or some kind of diagram to make sure in the future we use exceptions consistently.
Actions