multex
Class Failure

java.lang.Object
  java.lang.Throwable
      java.lang.Exception
          java.lang.RuntimeException
              multex.Failure

All Implemented Interfaces:

MultexException, java.io.Serializable

Direct Known Subclasses:

AssertionFailure

public class Failure

extends java.lang.RuntimeException

implements MultexException

Indirectly caused exception with parameters, causal chain and internationalizable message text. This class serves for the framework user as a base class for defining Failure-exceptions. Objects of this class can be thrown, too, but such exceptions cannot be handled individually nor get internationalized. Failure-exceptions have the following benefits:

• coherent usage always for unexpected failure of an operation
• reduce the amount of exceptions to specify in the throws-clause from many unexpected exceptions to only one
• chance to provide the failure of an operation with a message text, message parameters and a chain of the unexpected causing exceptions.

The (unnamed, indexed) exception parameters are handled the same way as in class Exc.

Naming convention: All user-defined exception classes derived from Failure should have a name ending in Failure. The pattern is:

      class OperationnameFailure extends Failure { ... }
    

Failure as unchecked exception?

It can be bothering always to specify Failure in the throws-clause of any method, that calls other non-trivial methods. This holds especially, when you are converting an existing software system to usage of MulTEx. Thus Failure inherits the unchecked java.lang.RuntimeException.

So you can specify Failure, but you need not to do this. This is in my opinion not the cleanest way, but even without Failure you could not base on the assumption, that a method without a throws-clause does not throw any exception. Any method could throw any java.lang.RuntimeException, e.g. the IndexOutOfBoundsException.

If you want to strictly check Failure, then you can change the superclass of Failure to the checked java.lang.Exception instead of the unchecked java.lang.RuntimeException. Up to now I am not sure, what is the best way. Please report your experiences.

Author:

Christoph Knabe, knabe@tfh-berlin.de, TFH Berlin, 1999-2005

See Also:

Serialized Form

Field Summary

static java.lang.String

className The unqualified name of this class