Question

in OO programming, is there some conceptual pattern, ideas, about handling multiple errors?

for example, i have a method that performs some checks and should return an error message for each error found

[‘name is too short’, ‘name contains invalid unicode sequences’, ‘name is too long’]

now, should i use an array of exceptions (not thrown exceptions)?

or something like this is better:

class MyExceptionList extends Exception{
  public Void addException(Exception e){}
  public Array getExceptions(){}
}

any theory behind this argument will be appreciated!

(this isn’t a request about a specific programming language, but a pure theoretical one)

thank you in advance

Answer 1

Unfortunately, many languages and frameworks (including C++, Java, and .net) use an exception-handling mechanism which requires the type of an an exception object to simultaneously answer many questions, including:

1. What happened
2. What actions need to be taken beyond stack unwinding
3. At what point should the system be considered to be in a “known” state, at least with regard to the problems indicated by the exception.

Unfortunately, while the answers to those questions are somewhat related, they are in reality far from 100% correlated. Unfortunately, the assumption that the type of an exception will be sufficient to answer all of those questions makes it difficult to deal sensibly with many situations.

If you have control over all the exceptions that can be thrown, it may be helpful to use an exception-handling paradigm where the exception-handling object includes a virtual IsResolved property or method along with a ShouldCatchAs<T> property or method that returns a T if the exception needs to be handled as a T. Such a paradigm would be able to smoothly handle situations where an exception occurs while unwinding the stack from an earlier exception (the existing exception and new one would be wrapped into a composite exception object, whose ShouldCatchAs property would combine those of the original exceptions, and whose IsResolved property should only return true when both of the original exceptions’ IsResolved properties do likewise).

I don’t know any way to integrate such behavior into the existing frameworks unless one catches and wraps all exceptions that don’t fit the paradigm, but perhaps future frameworks can facilitate such things.