> On 05/16/11 21:00, Vlad Khorsun wrote:
>>
>> We can introduce some special mode to report such errors using
>> exceptions,
>> or write message into log, or even provide callback for debugging purposes.
>>
>> But Adriano's question was about *semantics*. So, do you agree with me
>> that
>> explicit detach() must be called by good code and not just release() ? And
>> that
>> call of release() when refCount == 1 is a bug in caller's code ?
>
> My initial thinking was - for objects, that have explicit dtor functions
> (detach/commit/etc.), explicit dtor() must be called by good code and
> not just release().
Here we are agree, ok.
> But calling release() with refCount == 1 is not always bug. It's
> (logically) like handling errors in dtors - sometimes it's better to
> ignore error in dtor cause it can be already called due to another
> error. And if some thread needs to tell to the object - I do not need
> you any more, I anyway can't handle an error if it happens, why not let
> it call release()? As I've already said, logically this does not differ
> from lost network connection.
It is almost true. Almost, because in the case of unrecoverable error
in detach() we must offer *correct* way to release attachment and all
underlying objects. For remote interface we have
fb_cancel_operation(...fb_cancel_abort...)
which forcebly closed connection and (should) allow to free all other
handles in usual way.
I can't imagine unrecoverable error in, say, statement->drop(), which is
not related to the same unrecoverable error in detach(), so forced close
of attachment is enough for us.
If we have explicit destructor - we *must* use it. Else remove it and use
release() always. Is it wrong ?
Regards,
Vlad
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
