Re: [Flamerobin-devel] Re: [fr-cvs] mghie/src/gui MetadataItemPropertiesFrame.cpp,1.22,1.23

[Olivier M. <om-...@ti...>]

On 9/09/2005 14:27 GMT+1, Michael Hieke wrote:

>> There may still have some of those, but much fewer nowadays. Did you
>> retested recently without disabling them in debugging options ?
> 
> They are still in 2.3.5.0, and let me test... yes, they are still in 
> 2.4.0.1.

Okay, I've got a job for this week-end then.

> No, my problem with IBPP is that there are places where destructors call 
> functions which may throw, so they wrap this in "do nothing" exception 
> handlers.  Since exceptions in destrcutors are a no-no, what's the point 
> in raising them in the first place?

a) Destructors throwing exceptions is a well-known no-no Michael.
I 100% agree. That would be a mistake, and if there is such a destructor 
in IBPP, I need to fix it.

b) Destructors catching exceptions is not a no-no. And AFAIK that's what 
some destructors of IBPP do. They call some method that might very well 
throw and catch those so that these destructors can continue their work 
completely and correctly. A different beast.

I must though confess that some of those destructors do things like 
calling a close() that may throw if the thing was not previously open(). 
As such one can prefer to keep a flag and call close() only if open(). 
And this could be pushed further in the IBPP code. I agree.

>> It is often good to set the compiler to stop on C++ exceptions only
>> when those are uncaught and to leave the program run without
>> mentioning anything when a C++ exception is thrown as long as it is
>> catched somewhere.
> 
> Well, that is surely possible, but I like to be able to inspect the 
> local variables, the stack etc. when I encounter an exception.  That 
> beats being notified after the stack has been completely unwound.

With MSVC at least, you can give different instructions to the debugger, 
   so that it doesn't stop on IBPP::Exception kind of exceptions, but 
does so on anything else.

> Short description of the problem:  StatementImpl::CursorFree() can leave 
> the statement object in an unusable state.  Ending a transaction 
> releases the attached statement handles.  The statement object does not 
> know about that, so it has its mResultSetAvailable member set to true. 
> Now trying to do anything with that object will first call CursorFree, 
> which throws because dsql_free_statement() does not succeed.  Which is 
> the right thing, because the statement handle is invalid, it can't be 
> freed.  The missing part is the check for that particular IB error code. 
> The Right Thing to do is to not throw an exception in this case, but to 
> set mResultSetAvailable to false.
> 
> As the IB return codes are never checked after such API calls - I can 
> only assume that there are more such places where IBPP throws without a 
> convincing reason.  This particular exception I get 10 times when 
> connecting to a database...

Okay, I will really have a closer look and fix to this.

> I'm not against exceptions.  I'm against exceptions in certain cases, like:
> 
> - Throwing when there is enough information to correct the problem right 
> there.
> - Throwing when there is no stack to unwind, and the calling level 
> ignores the exception anyway.  See CursorFree(), when called in the 
> destructor.

Point taken.

> - Calling an object method, which would perform an action that has 
> already been performed.  Like Disconnect() on a disconnected database. 
> There's a lot of those in IBPP.  The intent of Disconnect() is not to 
> disconnect at this precise moment in time, but to make sure that the 
> database is not connected.  There's just no practical gain in throwing 
> an exception when the database is not connected.

I see. Throwing if asked to disconnect though it is already disconnected 
helps discover logic errors in the calling program. But that may not be 
a good idea. It's quite the same thing as MSVC telling me about a 
constant conditional when I code while(true) and know what I'm doing. I 
don't like that so I understand that you feel the same about some 
exceptions IBPP can report to try to help while you know what you are 
doing. I shouldn't code behaviours I don't myself appreciate in other 
places and context.

Thanks for this usefull discussion,

-- 
Olivier Mascia