STL usage and exception

[Dimitry Sibiryakov]

Hello All,

with growing usage of STL in Firebird codebase we have one big problem: old
code properly handles only Firebird::Exception so when STL classes throw, the
exception goes strait up to CLOOP envelopes which cause very ill effects.
I observed, for example, AV as the result of access to already released
ITransaction interface in ISQL.
I see no solution for that simpler than review and modify every catch block
in whole source tree.

--
WBR, SD.

[Alex Peshkoff]

On 3/31/26 15:33, 'Dimitry Sibiryakov' via firebird-devel wrote:
> Hello All,
>
>   with growing usage of STL in Firebird codebase we have one big
> problem: old code properly handles only Firebird::Exception so when
> STL classes throw, the exception goes strait up to CLOOP envelopes
> which cause very ill effects.

Yes, bad-bad.

>   I observed, for example, AV as the result of access to already
> released ITransaction interface in ISQL.

That's quite possible without STL - use of any piece of deallocated RAM
often cause AV.

>   I see no solution for that simpler than review and modify every
> catch block in whole source tree.
>

What else errors may STL containers throw except out of memory condition?

[Dimitry Sibiryakov]

Alex Peshkoff wrote 02.04.2026 13:12:
> What else errors may STL containers throw except out of memory condition?

How I found it:

Edit AlterIndexNode::execute() that uses MetaId, derived from std::optional,
and make it throw std::bad_optional_access per specs.

I'm thinking about `typedef std::exception Exception` and make
`stuffException` a non-member. In this case it will be able to recognise and
handle all kinds of exceptions as every `catchException` envelope do.

--
WBR, SD.

[Dimitry Sibiryakov]

Alex Peshkoff wrote 02.04.2026 13:12:

> That's quite possible without STL - use of any piece of deallocated RAM often
> cause AV.

The problem is that in this piece of code (where I got it) the object is not
supposed to be deallocated yet, still rollback() crashed:

(*x)->commit(fbStatus);
if (ISQL_errmsg (fbStatus))
{
(*x)->rollback(fbStatus);


--
WBR, SD.

[Vlad Khorsun]

02.04.2026 14:19, 'Dimitry Sibiryakov' via firebird-devel:

Why not inherit Exception from std::exception ?

Regards,
Vlad

[Dimitry Sibiryakov]

Vlad Khorsun wrote 02.04.2026 13:23:
>   Why not inherit Exception from std::exception ?

In this case existing blocks `catch (Exception& ex)` won't be able to catch
std::exception and amount of required changes will be doubled: not only call of
stuffException need change, but the declaration of the handler as well.

--
WBR, SD.

[Dmitry Yemanov]

02.04.2026 14:26, 'Dimitry Sibiryakov' via firebird-devel wrote:
>
>   In this case existing blocks `catch (Exception& ex)` won't be able to
> catch std::exception and amount of required changes will be doubled: not
> only call of stuffException need change, but the declaration of the
> handler as well.

Inherit Firebird::CustomException from std::exception, all other
exceptions - from Firebird::CustomException, then typedef
Firebird::Exception as std::exception.


Dmitry

[Dimitry Sibiryakov]

Dmitry Yemanov wrote 02.04.2026 13:46:
> Inherit Firebird::CustomException from std::exception, all other exceptions -
> from Firebird::CustomException, then typedef Firebird::Exception as std::exception.

What's the difference? Existing ex.stuffException() calls will have to be
replaced anyway.

--
WBR, SD.

[Dmitry Yemanov]

02.04.2026 14:49, 'Dimitry Sibiryakov' via firebird-devel wrote:
>
>> Inherit Firebird::CustomException from std::exception, all other
>> exceptions - from Firebird::CustomException, then typedef
>> Firebird::Exception as std::exception.
>
>   What's the difference? Existing ex.stuffException() calls will have
> to be replaced anyway.

All existing handlers will catch std::exception -- that's the
difference. But yes, ex.stuffException() are to be changed.


Dmitry

[Dimitry Sibiryakov]

Dmitry Yemanov wrote 02.04.2026 13:53:
> All existing handlers will catch std::exception -- that's the difference.

That's the result of the typedef, and why I suggested it from the beginning.
Firebird::CustomException is not needed for this as every Firebird exception is
already derived from Firebird::Exception (except FbException which is not used
by Firebird code itself).

--
WBR, SD.