When we developed Java utility and page object classes, we added exception handling to the methods. In some cases, methods can include specific exception types or just throw general exception conditions. Users often use the try...catch...finally syntax to trap exceptions and handle them using a custom set of actions, but using this syntax should not be exclusive. We want exceptions to occur implicitly or explicitly so we get the exception type and stack trace for debugging.

Page object methods called from within test methods can also throw exceptions when certain conditions are not met. So, at any point in the test, an exception could "break" out of the test method and turn over control to the @AfterMethod, routine per TestNG. It's the same when all test methods are complete, an exception in the @AfterMethod routine will turn over control to the @AfterClass routine, and so on.

Here is an example of a test method that can exit in multiple places. First, the method can throw an exception if the data file is not found. Second, when it loads the properties file, it can throw an IOException if the properties file is not found. And finally, the TestNG assertEquals method can throw AssertionError if the Selenium revision is not matched with the expected value (using TestNG's assetEquals to test Strings, Integers, Objects, and so on will engage the difference viewer if the condition is not met, which is a useful tool):

@Test
public void tc001_readPropertyFile(String rowID,
                                   String description,
                                   JSONObject testData)
                                   throws IOException, AssertionError {

    Properties seleniumProps = new Properties();
    String propFile = testData.get("propFile").toString();
    String expRevision = testData.get("revision").toString();

    seleniumProps.load(new FileInputStream(propFile));
    assertEquals(seleniumProps.getProperty("selenium.revision"),
                 expRevision,
                 "Verify Selenium Revision");
}