Feature #95


Restructure Exceptions

Added by Tobias Wich over 11 years ago. Updated over 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Build Version:


Exceptions are used pretty inconsistent in the code base. In some places it is pretty good, but especially the quick hacks lack good style and an error definition sufficient to base other parts on.

There are some points which I try to summarize here. We should discuss them in this issue and create a plan to address them in version:1.0.0-pre2

  1. Define a way to end the application in case of a fatal error.
    The original plan was to use RuntimeExceptions to terminate the program, when a severe error, such as an unavailable PCSC stack or any other unrecoverable initialization error, occurs. The current situation is, that a lot of code paths catch the type Exception, which also includes RuntimeException.
    Using Error types for that kind of errors would solve the termination problem, but using those types is considered bad practice and raises other issues depending on the type of error (see Furthermore there is the problem, that we the eCard interfaces (IFD, SAL) must not throw exceptions at all. Those interfaces must return a suitable result. Exceptions (or in the case of SOAP) SOAPFaults are not defined in the specification.
  2. Catching the type Exception or even Throwable should not be used.
    As elaborated in the last point, some functions must not throw any exceptions. The IFD and to some degree the SAL catches Throwable. My proposition to this problem is shown in the following code fragment. This of course is without a solution from the last point.
    } catch (Exception e) {
        if (e instanceof RuntimeException) {
            throw e;
        // handle exception and provide result message
  3. ECardException should be the base type for all eCard-API funtions and their encapsulated code paths.
    The ECardException base type provides OASIS Results which are necessary in all eCard API functions, so they are a must for all exceptions which are subject to be caught by those functions. Maybe it is a good idea to base most exceptions in the Open eCard project on this type.
  4. Every module should define a sensible exception hierarchy

What points did I forget?

When we have found a satisfying solution, we should write it down as an entry in code-style.

Actions #1

Updated by Detlef Hühnlein over 11 years ago

  • Target version changed from 5 to 8
Actions #2

Updated by Tobias Wich over 11 years ago

  • Target version changed from 8 to 10
Actions #3

Updated by Tobias Wich almost 11 years ago

  • Target version deleted (10)
Actions #4

Updated by Tobias Wich almost 10 years ago

  • Target version set to 1.x
Actions #5

Updated by Tobias Wich over 8 years ago

  • Tracker changed from Bug to Feature
Actions #6

Updated by Tobias Wich over 5 years ago

  • Status changed from New to Rejected

The code has already changed quite a bit and does not have the problems in general anymore.


Also available in: Atom PDF