Test, Exception Handling - epam/Gepard GitHub Wiki

Please follow these Exception handling rules, it is applicable on test automation code that is using Gepard.

Avoid catching "super" exceptions, like this:

catch (Exception e)  {
   // whatever
}

or this:

catch (Throwable t)  {
   // whatever
}

Instead of it, use as many catch blocks as many exception type you would like to catch. Additionally:

• Avoid catching InterruptedException, ExecutionException or CancellationException
• Do not use any external object (even if that seems to be accessible by using the GepardTestClass interface) in any thread created by you after you receive any of InterruptedException, ExecutionException or CancellationException
• The following exception handling is OK

a, if you would like to avoid the chain of "throws XXXXException" in the methods, like this:

try {
    // whatever
} catch (AnException e) {
    throw new SimpleGepardException("We have a problem: " + e.getMessage());
}

b, if you re-throw the same or another ex, like:

catch (WhatEverEx e) {
    // whatever you would like to do, but if you have your own thread, do not use external objects, just thread internal ones
    // ...
    throw e;  // or throw new AnotherException(e)
}

Details of these rules

We face time to time with bad catch usage in Test codes, which cause serious problems for Gepard maintainers. You must know that exceptions are used to fail the test case, interrupt the execution of the test case, make it N/A, etc. A good exception handling therefore is a critical point in the test code. 

The root cause of the problems is the incorrect handling of InterruptedException, ExecutionException or CancellationException. These exceptions are thread related exceptions and in a multi-threaded application (like Gepard) when several tests may run in parallel and concurrent, you should handle them with extra care.

Let me show a bad example:

} catch (InterruptedException e) {
    logComment(e.getMessage());
}

InterruptedException may occur for example when timeout happens in Gepard. In the code above this event was simply ignored, and the test continues. Especially if you have your own thread in the test, it is not guaranteed, that the logComment method or any of its inner object still exist/valid + the code shows that the thread did not stop, just continue, which is simply unacceptable.

So we kindly ask you to follow the listed rules above to avoid the possibility of undetermined status of Gepard and the test results.

Thank you for your understanding.