Exception handling in install

The JCRE specification does not describe how the exceptions thrown from the install command should be handled. The reason for this is that these exceptions are supposed to be handled by an installer application, and the JCRE specification (¶11.1.5)explicitly states:

Java Card RE implementers shall also define other behaviors of their Installer, including (…) what happens if an exception, reset, or power fail occurs during installation.

In most Java Card implementations, the GlobalPlatform card specification is used as a reference for the implementation of the Installer. An applet’s install method is invoked during the execution of an INSTALL [for install] command, and the definition of this command does not define any precise behavior if the installation of the application fails.


In practice, many different cases may occur. First, it depends on when the application fails

  • The application throws an exception before to invoke Applet.register. In that case, according to the Java Card specification, the installation is deemed unsuccessful. The INSTALL command shall therefore fail.
  • The application throws an exception after invoking successfully Applet.register. In that case, according to the Java Card specification, the installation is deemed successful, despite the exception. In that case, the outcome of the INSTALL command is not completely clear.
  • The application throws an ISOException. If this occurs in the Applet.process method, the exception’s reason is returned as status word.
  • The application throws any other exception. If this occurs in the Applet.process method, the Java Card RE returns the status word 6F00 (Unknown error).

These different cases lead platform developers to make two choices: whether or not to the INSTALL command shall succeed if an exception is thrown after successful registration, and which status word to return when the INSTALL command fails. On the first issue, there are two possible interpretations:

  • The INSTALL command should fail whenever the install method ends with an exception. The rationale behind this choice is that an error should never go unnoticed, and that the user needs to be warned of the error.
  • The INSTALL command should succeed whenever the applet instance has been successfully registered. The rationale behind this choice is that the result of the INSTALL command shall reflect the overall result of the execution, i.e. the fact that the instance has been registered.

About the exception to be returned, there also are several possible interpretations:

  • The INSTALL command should return the same status word as the Java Card RE would return from the Applet.process method. The argument is here that the information provided by the application about the reason of the failure should not be lost.
  • The INSTALL command should always return a status word listed in its specification. This means that the status code implied by the exception shall be ignored, and that a standard GlobalPlatform exception shall be returned, for instance 6400 (No specific diagnosis) or 6985 (Conditions of use not satisfied). The argument is here that a GlobalPlatform command should not return status words that the terminals may not expect.

In both cases, the arguments from both sides are acceptable, which means that there is no strong decision to take. My own opinion is that the INSTALL command should succeed whenever the applet instance has been successfully registered, and it should always return a status word listed in its specification.

The conclusion is that an application should not rely on any of these behaviors if it needs to be portable between platforms. The best solution is to avoid throwing exceptions (a simple return before registration is enough to abort the installation), and to avoid putting code after the call to Applet.register. This is easy to do, except for SIM Toolkit applications, which usually need to do some operations after the applet’s registration. We’ll see how to do that correctly in another post.

No Comments

Leave a Reply

Your email is never shared.Required fields are marked *