[fdo-dev] Catching exceptions in FDORDBMS Unit Tests
mateusz at loskot.net
Fri Sep 8 22:59:42 EDT 2006
Frank Warmerdam wrote:
> On 9/5/06, Mateusz Loskot <mateusz at loskot.net> wrote:
>> Recently, I started to play with Unit Tests in details and
>> I'm not sure I understand how they are expected work.
>> First, I see the main() function, in file UnitTest/Common/UnitTest.cpp,
>> is *not* wrapped with try-catch.
>> Hmm, so where exceptions (most of them) are supposed to be
>> caught, for example to print some meaningful message
>> (e.g. using FdoException::GetExceptionMessage())
>> and terminate execution?
> I have come to the conclusion that part of the CppUnit
> test harnass (TextTestRunner?) is in fact trapping all
> exceptions within the test operations. So, this is a
> need that is already anticipated by the test harnass.
OK, if the test traps exceptions and I the program does not
aborts on exception thrown, then it's correct and expected behavior.
But in FDORDBMS, exception is uncaught and program
> Of course, that doesn't explain why things aren't working
> for you. I too have had very anomolous results on Linux
> when unexpected exceptions are fired.
> I was unable to
> determine why, and I suspect there is something
> questionable in my build environment. Perhaps a
> flaw in the version of g++ or the c++ runtime options
> in place.
Did these anomalous occur in FDO or other projects too?
I'm trying to say, I've never meet anything "unexpected" with
exceptions handling on Linux.
If any function is supposed to throw exception, then
if called, it should be wrapped by try-catch or program termination
is accepted as expected behavior on uncaught exception.
Exceptions are usually expected, or better, possible to occur ;-)
I've met unexpected issues on Windows, where some hacks are required:
See "Note for Windows developers" and below this section)
What I suppose here is a kind of compilation issue,
incorrect or missing options, but I've not investigated it.
> Hopefully we will learn more in the future. In the
> meantime, if I step through to track unexpected
> exceptions, and "fix" them I find the unit tests
> (for fdogdal in my case) do work ok on Linux.
I'd not agree it's a very convenient solution in my case.
For example, when I want to write a Unit Test that tests
handling of correct and incorrect connection string,
then I have to base on exceptions.
More information about the Fdo-internals