exception in fbclient during first isc_attach_database

[ppazera]

Hello,

when firebird.conf is not found on client machine
firebird v5.0.2 classic on windows (we are trying to migrate from v2.5.9)
c++ exception is raised when trying to make first connection to first database
we develop in Delphi and use vectoredExceptionHandler, it logs all exceptions even if they are caught and ignored by fbclient code itself
Delphi does not understand c++ call stack nor arguments nor exceptions, it just reports Exception code E06D7363
but I was able to extract following call stack using MS tools:

00000000`1431f820  636210b9 fbclient!isc_attach_database+0x249 [C:\firebird-build\src\yvalve\why.cpp @ 1656]
00000000`1431f4d8  6363e43a fbclient!Firebird::Config::getDefaultConfig+0xa [C:\firebird-build\src\common\config\config.cpp @ 475]
00000000`1431f4a8  6363d80d fbclient!Firebird::InitInstance<`anonymous namespace'::ConfigImpl,Firebird::DefaultInstanceAllocator<`anonymous namespace'::ConfigImpl>,Firebird::DeleteInstance>::operator()+0x7d [C:\firebird-build\src\common\classes\init.h @ 284]
00000000`1431f268  6363d42b fbclient!`anonymous namespace'::ConfigImpl::ConfigImpl+0x7b [C:\firebird-build\src\common\config\config.cpp @ 65]
00000000`1431f1f4  6365d467 fbclient!ConfigFile::ConfigFile+0xb7 [C:\firebird-build\src\common\config\config_file.cpp @ 223]
00000000`1431f1cc  6365d78b fbclient!`anonymous namespace'::MainStream::MainStream+0xdb [C:\firebird-build\src\common\config\config_file.cpp @ 70]

looks like the problem is in MainStream::MainStream when firebird.conf is not found (on client machine where it's not required)
Would it be possible eliminate this exception in future v5 version?

Thanks,
Paulius (GLDS)

[AlexPeshkoff]

On 4/15/25 17:27, ppazera wrote: we develop in Delphi and use vectoredExceptionHandler, it logs all exceptions even if they are caught and ignored by fbclient code itself

That's very strange behavior. When making any call to foreign DLL software should not try to interact with that thread (except when callbacks are done) as long as control is not returned to the caller. Such calls should behave like calls to "black box". Certainly that's not absolute rule for any debug cases but in release build such interaction looks very strange not to say more. We actively use exceptions, including client library, and I doubt it will be possible to avoid all of them - we switched to that way in FB3 and that never caused problems. Can vectoredExceptionHandler be turned off in some way during call to our API? If yes probably we can think about adding a hook to our prologue code of most of API calls to turn that behavior off/on?

[hvlad]

we develop in Delphi and use vectoredExceptionHandler, it logs all exceptions even if they are caught and ignored by fbclient code itself
Delphi does not understand c++ call stack nor arguments nor exceptions, it just reports Exception code E06D7363

You may just ignore this kind of exceptions.
It is close to impossible to require that any loaded external library not used exceptions.

[ppazera]

thanks both for prompt responses

a bit of background why and when we use vectoredExceptionHandler. In our code we use regular exception handlers and we have our 'normal' logs (categorized and prioritized), in most cases we use those. But we also use third party libraries built into our EXEs which may create their own threads, and third party DLLs where we can't attach our exception handlers, thus we use vectoredExceptionHandler to investigate issues which are not logged into our 'normal' logs. This vectoredExceptionHandler logging is turned on only during investigation (because it is quite chatty), and over years it turned out to be very useful, because defects are not only in our code, but also in third party code we use. And when we need it, we need all errors and exceptions in there to see whole picture, to be able to spot tiny clues which could be relevant to issues we are investigating

I saw multiple fbclient exceptions in there, during prepare, during fetch, etc. Most likely they are converted to errors, we see them in our application, we fix either queries, or parameters, or SPs or repair DB and they are gone. I'm not asking to eliminate those, they are useful indicators about issues and help us fix them. But this particular exception seems different, it does not indicate any problem, firebird.conf is not required on client side, fbclient works fine without it. Maybe instead of raising exception it could return error code so that caller can skip loading parameters from it. Just a thought. It would help other developers like us to keep vectoredExceptionHandler log cleaner, without expected exceptions, without flooding and hiding real unexpected errors. Because right know we use some other libraries which overuse exception raising for internal communication and we have to check each call stack and remember which one is expected non-issue and ignore them (missing c++ exception text and call stack makes it more difficult)

sorry for long post, hopefully now it's more clear why I registered this item and prior #8522

[hvlad]

Reopen for backporting