Exception program control was introduced into programming languages to help developers to easily handle program error flows. But if you use exception in the wrong way, they could also be the source of software bugs. The post is aligned with the Black Box Software Testing Foundations course (BBST) designed by Rebecca Fiedler, Cem Kaner, and James Bach.
When a developer creates some function, it must handle failure conditions and report those to the user of a function. Errors could be reported through return error codes or via Exceptions. The exception mechanism offers immediate halt of program execution if the user of function does not handle that exception.
Here is an example of how to handle previous ArithmeticError exception:
try do :foo + 1 rescue ArithmeticError -> "Error!" end
This code snippet would catch ArithmeticError, report it with “Error” string, and continue with execution.
The most famous example for all programming languages is divide by zero. Or when we try to open a file from none existing path.
Common bug is when an exception comes from s resource (file, network, device), and the developer does handle the exception, but leaving that resource in the unexpected state (e.g., the file is not closed, network stream is not close.)
The actual bug would be triggered when a program tries latter to access those resources.
What Can You Do?
Learn how the programming language of your application under test handles exceptions. Then search the codebase for those keywords. Risk is if you do not find those keywords! Then search code base for resources (Files, devices, networks) and check do those calls use exception handling. Identify in application areas that operate with resources. Try to generate conditions that would trigger an exception.