Description
ITK exceptions are largely non-specific, i.e. a general itkExceptionMacro can loosely used to throw virtually any type of exception. Making exceptions be more specific, including the messages, would make the toolkit more consistent.
At the same time, the TRY_EXPECT_EXCEPTION macro is non-specific, meaning that it expects the statement to throw an exception, whichever the exception is. When writing such a statement in a test, the programmer generally expects a specific exception to be caught, i.e. an exception with a known message to be thrown. However, if the code is not designed correctly or hides a bug, the statement may well catch an exception, but one that has been thrown elsewhere/is different from the one expected. The test or macro would work correctly, because it does not check the exception type (or better, the source of the exception, or both).
PR #511 uncovered such a situation.
Impact analysis
Having non-specific exceptions provides a flexible framework, but may hide bugs. Also, if there is no way to check the exception type and/or the class that threw it, when expecting an exception, any other exception thrown in the call stack may be considered as a valid exception
Expected behavior
Creating a specific set of exceptions and enhancing the TRY_EXPECT_EXCEPTION to accept the class and exception type would help in making the code more consistent, and robust.
e.g.
TRY_EXPECT_EXCEPTION( filter->Update(), FilterClass, ExceptionType );
Actual behavior
Current exception checking:
TRY_EXPECT_EXCEPTION( filter->Update() );
Versions
master.
Additional Information
None.
Description
ITK exceptions are largely non-specific, i.e. a general
itkExceptionMacrocan loosely used to throw virtually any type of exception. Making exceptions be more specific, including the messages, would make the toolkit more consistent.At the same time, the
TRY_EXPECT_EXCEPTIONmacro is non-specific, meaning that it expects the statement to throw an exception, whichever the exception is. When writing such a statement in a test, the programmer generally expects a specific exception to be caught, i.e. an exception with a known message to be thrown. However, if the code is not designed correctly or hides a bug, the statement may well catch an exception, but one that has been thrown elsewhere/is different from the one expected. The test or macro would work correctly, because it does not check the exception type (or better, the source of the exception, or both).PR #511 uncovered such a situation.
Impact analysis
Having non-specific exceptions provides a flexible framework, but may hide bugs. Also, if there is no way to check the exception type and/or the class that threw it, when expecting an exception, any other exception thrown in the call stack may be considered as a valid exception
Expected behavior
Creating a specific set of exceptions and enhancing the
TRY_EXPECT_EXCEPTIONto accept the class and exception type would help in making the code more consistent, and robust.e.g.
Actual behavior
Current exception checking:
Versions
master.Additional Information
None.