As it turns out, it is actually rather difficult to test an exceptions such as these. We are catching programming errors. How does one trigger such exceptions? By running a test that finds a programming bug. What is the proper response? Fix the bug so that it never occurs again. As a result, your exception test no longer tests the exception because the exception no longer occurs. This is why it is so hard to catch specific programming errors: by definition, they should never occur.
However, if we catch exceptions at the fragment executor level, then Drill does have a way to trigger an exception using the error injection framework. Basically, pick a point in the code (perhaps in one of the readers) an call the error injector. If it is enabled, it will throw the requested exception. You can then verify that the error is as expected. And, since the error is intentionally injected, you can repeat this test as often as you like. You could use this framework to inject exceptions every time an IOBE could occur, but that seems very awkward indeed. Error injection is usually for injecting expected errors, such as OOM, disk I/O errors, file not found, and the like. Error handling is a tricky topic, which is why I'm jumping in to offer suggestions based on my time in "the school of hard knocks." [ Full content available at: https://github.com/apache/drill/pull/1455 ] This message was relayed via gitbox.apache.org for [email protected]
