How Ocaramba Handles Custom Exceptions: A Deep Dive into WaitTimeoutException and DataDrivenReadException

Ocaramba handles custom exceptions by defining domain-specific types—WaitTimeoutException and DataDrivenReadException—that inherit from System.Exception and provide three standard constructors for consistent error handling in .NET test automation.

The accenture/ocaramba framework provides a robust structure for handling errors in automated testing scenarios. Understanding how Ocaramba handles custom exceptions is essential for writing resilient test code that can distinguish between timing failures and data parsing errors. This article examines the implementation details found in the OcarambaLite/Exceptions directory and demonstrates how these exception types integrate with helper utilities like WaitHelper and data-driven test infrastructure.

The Architecture of Ocaramba's Custom Exceptions

Ocaramba defines custom exceptions within the Ocaramba.Exceptions namespace to provide typed error information that is specific to test automation domains. Unlike generic System.Exception types, these custom classes allow test code to implement precise catch blocks for different failure modes.

WaitTimeoutException for UI Synchronization

The WaitTimeoutException class signals that a waiting operation exceeded its allotted time before meeting the specified condition. This exception is critical for UI test automation where elements may load asynchronously. According to the source code in OcarambaLite/Exceptions/WaitTimeoutException.cs, this type inherits directly from System.Exception and includes no additional state beyond the standard message and inner exception properties.

DataDrivenReadException for Test Data Management

The DataDrivenReadException class indicates failures during the loading or parsing of data-driven test inputs, such as CSV or Excel files. Located in OcarambaLite/Exceptions/DataDrivenReadException.cs, this exception type enables test suites to distinguish between test logic errors and data provisioning failures. This separation allows automation engineers to implement specific recovery strategies when test data is unavailable or malformed.

Implementation Details in OcarambaLite/Exceptions

Both custom exception classes follow the standard .NET exception pattern by providing three constructors:

1. A parameterless default constructor
2. A constructor accepting only a message string
3. A constructor accepting both a message and an inner exception

This implementation pattern ensures compatibility with serialization requirements and provides flexibility for different error scenarios. The classes reside in the OcarambaLite/Exceptions directory, making them accessible to both the core framework and consuming test projects.

The following files define these exception types:

• OcarambaLite/Exceptions/WaitTimeoutException.cs
• OcarambaLite/Exceptions/DataDrivenReadException.cs

How WaitTimeoutException Works in Practice

The WaitHelper class in OcarambaLite/Helpers/WaitHelper.cs utilizes WaitTimeoutException to communicate timeout failures during conditional waits. When the Wait method exhausts its timeout duration without the condition returning true, it throws this specific exception with a formatted message indicating the elapsed time and the failure context.

if (!result)
{
    throw new WaitTimeoutException(
        string.Format(CultureInfo.CurrentCulture,
                      "Timeout after {0} second(s), {1}",
                      timeout.TotalSeconds, message));
}

Test code can catch this exception to implement specific timeout handling logic, such as taking screenshots or retrying with different parameters.

Handling Data-Driven Test Failures with DataDrivenReadException

The DataDrivenReadException is employed by the data-driven testing infrastructure when parsing external data sources fails. Located in the data-driven helper utilities, this exception wraps underlying I/O or parsing errors while adding context about the specific test data file and operation being performed.

When loading test data from CSV or Excel files, the framework attempts to parse the content and map it to test parameters. If this process encounters malformed data, missing files, or format incompatibilities, it throws DataDrivenReadException with the original exception preserved as the inner exception.

try
{
    var testData = DataDrivenHelper.ReadCsv("TestData.csv");
}
catch (DataDrivenReadException ex)
{
    logger.Error("Failed to read test data: " + ex.Message);
    // Fallback or abort the test suite
}

Best Practices for Catching Ocaramba Exceptions

When implementing error handling in test automation projects using Ocaramba, catch the specific custom exception types before falling back to generic Exception handlers. This approach enables targeted responses to different failure modes.

using Ocaramba.Helpers;
using Ocaramba.Exceptions;

public void VerifyFileIsCreated(string path)
{
    try
    {
        WaitHelper.Wait(() => System.IO.File.Exists(path),
                        TimeSpan.FromSeconds(30),
                        "File was not created in time");
    }
    catch (WaitTimeoutException e)
    {
        Console.WriteLine($"Timeout while waiting for file: {e.Message}");
        throw;
    }
}

For data-driven scenarios, always wrap data loading operations in try-catch blocks that specifically handle DataDrivenReadException. This practice prevents test execution failures from cascading when test data is temporarily unavailable.

Summary

• Ocaramba defines domain-specific exceptions—WaitTimeoutException and DataDrivenReadException—in the Ocaramba.Exceptions namespace to provide typed error information for test automation scenarios.
• Both exception types inherit from System.Exception and implement the standard three-constructor pattern (default, message-only, and message-plus-innerException) for compatibility with .NET exception handling conventions.
• WaitTimeoutException is thrown by WaitHelper.cs when conditional wait operations exceed their timeout duration, enabling specific handling for UI synchronization failures.
• DataDrivenReadException is utilized by the data-driven testing infrastructure to signal failures in loading or parsing external test data sources such as CSV or Excel files.
• Test code should catch these specific exception types to implement targeted error recovery, distinguishing between timing issues, data provisioning problems, and general application errors.

Frequently Asked Questions

What is the base class for Ocaramba custom exceptions?

Both WaitTimeoutException and DataDrivenReadException inherit directly from System.Exception. This design choice keeps the implementation simple while still providing strongly typed error information that can be caught separately from other exception types.

Where are Ocaramba custom exceptions defined in the source code?

The custom exception classes are located in the OcarambaLite/Exceptions directory within the repository. Specifically, WaitTimeoutException.cs and DataDrivenReadException.cs define these types within the Ocaramba.Exceptions namespace.

How do I catch a timeout exception in Ocaramba?

Import the Ocaramba.Exceptions namespace and catch WaitTimeoutException specifically when calling methods from WaitHelper. This allows you to implement custom logic for timeout scenarios, such as logging screenshots or retrying operations, while letting other exceptions propagate normally.

Can I create my own custom exceptions using Ocaramba's pattern?

Yes, you can follow the same pattern used by Ocaramba when defining your own test-specific exceptions. Create a class that inherits from System.Exception, place it in a meaningful namespace, and implement the three standard constructors (parameterless, message-only, and message-plus-innerException) to maintain consistency with .NET exception handling conventions and Ocaramba's architecture.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}