Abandon of the non-throwing version of C++ client API

[Igor Sapego]

Hi Igniters,

I'm the guy who mostly contribute in C++ Ignite client and I
need your advice. Mostly I'd like to hear from our users and
those who are experienced in C++. Currently we have two
versions of most API methods - the throwing one and the
one that returns error through output argument. This was initially
done because we were not sure which way of error-reporting
is going to be preferred by our users.

Now this approach bloats C++ API a lot and makes it harder to
maintain and optimize code. I propose like to abandon and deprecate
non-throwing version of API and only leave throwing version,
but first I want to hear from you guys - what do you think? Does
anyone use non-throwing version of the API? Maybe your toolchain
does not support exceptions or are you disabling them on purpose?

For those who prefer disabling exceptions I propose to introduce
some macros like IGNITE_DISABLE_EXCEPTIONS and add
some thread-local error-storing mechanism like ignite::GetLastError().

What do you guys think?

Best Regards,
Igor

[Denis Magda]

Hi Igor,

My C++ experience is based only on error code methods. This is why I
thought that exceptions based approach is unrelated to C++ at all.

I do remember we discussed all the pros and cons of these ways before.
Could you find that old discussion and share it here? I'm on a mobile now,
not easy to do on my own.

Denis

On Friday, January 20, 2017, Igor Sapego <[hidden email]> wrote:

> Hi Igniters,
>
> I'm the guy who mostly contribute in C++ Ignite client and I
> need your advice. Mostly I'd like to hear from our users and
> those who are experienced in C++. Currently we have two
> versions of most API methods - the throwing one and the
> one that returns error through output argument. This was initially
> done because we were not sure which way of error-reporting
> is going to be preferred by our users.
>
> Now this approach bloats C++ API a lot and makes it harder to
> maintain and optimize code. I propose like to abandon and deprecate
> non-throwing version of API and only leave throwing version,
> but first I want to hear from you guys - what do you think? Does
> anyone use non-throwing version of the API? Maybe your toolchain
> does not support exceptions or are you disabling them on purpose?
>
> For those who prefer disabling exceptions I propose to introduce
> some macros like IGNITE_DISABLE_EXCEPTIONS and add
> some thread-local error-storing mechanism like ignite::GetLastError().
>
> What do you guys think?
>
> Best Regards,
> Igor
>

[Vladimir Ozerov]

+1 to Igor's idea. Ignite is relatively high-level product and we do not
expect ultra-optimized users who cannot allow exceptions to be enabled.
Macros should be a good workaround for them, though.

On Sat, Jan 21, 2017 at 6:47 PM, Denis Magda <[hidden email]> wrote:

> Hi Igor,
>
> My C++ experience is based only on error code methods. This is why I
> thought that exceptions based approach is unrelated to C++ at all.
>
> I do remember we discussed all the pros and cons of these ways before.
> Could you find that old discussion and share it here? I'm on a mobile now,
> not easy to do on my own.
>
> Denis
>
>
> On Friday, January 20, 2017, Igor Sapego <[hidden email]> wrote:
>
>> Hi Igniters,
>>
>> I'm the guy who mostly contribute in C++ Ignite client and I
>> need your advice. Mostly I'd like to hear from our users and
>> those who are experienced in C++. Currently we have two
>> versions of most API methods - the throwing one and the
>> one that returns error through output argument. This was initially
>> done because we were not sure which way of error-reporting
>> is going to be preferred by our users.
>>
>> Now this approach bloats C++ API a lot and makes it harder to
>> maintain and optimize code. I propose like to abandon and deprecate
>> non-throwing version of API and only leave throwing version,
>> but first I want to hear from you guys - what do you think? Does
>> anyone use non-throwing version of the API? Maybe your toolchain
>> does not support exceptions or are you disabling them on purpose?
>>
>> For those who prefer disabling exceptions I propose to introduce
>> some macros like IGNITE_DISABLE_EXCEPTIONS and add
>> some thread-local error-storing mechanism like ignite::GetLastError().
>>
>> What do you guys think?
>>
>> Best Regards,
>> Igor
>>
>

[dmagda]

Guys,

I found the initial discussion from the early times of our C++ client:
http://apache-ignite-developers.2346864.n4.nabble.com/C-exception-handling-strategy-td778.html <http://apache-ignite-developers.2346864.n4.nabble.com/C-exception-handling-strategy-td778.html>

Vovan, that time you were on the side of error-code methods. Why have you changed you mind proposing to make the throwing version default one? Any new tendency in C++ community?

—
Denis

> On Jan 23, 2017, at 2:56 AM, Vladimir Ozerov <[hidden email]> wrote:
>
> +1 to Igor's idea. Ignite is relatively high-level product and we do not expect ultra-optimized users who cannot allow exceptions to be enabled. Macros should be a good workaround for them, though.
>
> On Sat, Jan 21, 2017 at 6:47 PM, Denis Magda <[hidden email] <mailto:[hidden email]>> wrote:
> Hi Igor,
>
> My C++ experience is based only on error code methods. This is why I thought that exceptions based approach is unrelated to C++ at all.
>
> I do remember we discussed all the pros and cons of these ways before. Could you find that old discussion and share it here? I'm on a mobile now, not easy to do on my own.
>
> Denis
>
>
> On Friday, January 20, 2017, Igor Sapego <[hidden email] <mailto:[hidden email]>> wrote:
> Hi Igniters,
>
> I'm the guy who mostly contribute in C++ Ignite client and I
> need your advice. Mostly I'd like to hear from our users and
> those who are experienced in C++. Currently we have two
> versions of most API methods - the throwing one and the
> one that returns error through output argument. This was initially
> done because we were not sure which way of error-reporting
> is going to be preferred by our users.
>
> Now this approach bloats C++ API a lot and makes it harder to
> maintain and optimize code. I propose like to abandon and deprecate
> non-throwing version of API and only leave throwing version,
> but first I want to hear from you guys - what do you think? Does
> anyone use non-throwing version of the API? Maybe your toolchain
> does not support exceptions or are you disabling them on purpose?
>
> For those who prefer disabling exceptions I propose to introduce
> some macros like IGNITE_DISABLE_EXCEPTIONS and add
> some thread-local error-storing mechanism like ignite::GetLastError().
>
> What do you guys think?
>
> Best Regards,
> Igor
>

[Vladimir Ozerov]

Originally I tried to cover situation when user disabled exceptions. In
this case throwing something will lead to application crash. However, for
now I believe that such use case is not very likely as Ignite is relatively
high-level product. For this reason I would prefer to keep clean and
compact API which will throw exceptions. But still have a workaround for
users which do not want that. For instance, we may consult to some
environment variable in runtime, or to some preprocessor flag in compile
time, and expose additional static "GetLastError" method.

On Mon, Jan 23, 2017 at 11:35 PM, Denis Magda <[hidden email]> wrote:

> Guys,
>
> I found the initial discussion from the early times of our C++ client:
> http://apache-ignite-developers.2346864.n4.nabble.
> com/C-exception-handling-strategy-td778.html
>
> Vovan, that time you were on the side of error-code methods. Why have you
> changed you mind proposing to make the throwing version default one? Any
> new tendency in C++ community?
>
> —
> Denis
>
> On Jan 23, 2017, at 2:56 AM, Vladimir Ozerov <[hidden email]> wrote:
>
> +1 to Igor's idea. Ignite is relatively high-level product and we do not
> expect ultra-optimized users who cannot allow exceptions to be enabled.
> Macros should be a good workaround for them, though.
>
> On Sat, Jan 21, 2017 at 6:47 PM, Denis Magda <[hidden email]> wrote:
>
>> Hi Igor,
>>
>> My C++ experience is based only on error code methods. This is why I
>> thought that exceptions based approach is unrelated to C++ at all.
>>
>> I do remember we discussed all the pros and cons of these ways before.
>> Could you find that old discussion and share it here? I'm on a mobile now,
>> not easy to do on my own.
>>
>> Denis
>>
>>
>> On Friday, January 20, 2017, Igor Sapego <[hidden email]> wrote:
>>
>>> Hi Igniters,
>>>
>>> I'm the guy who mostly contribute in C++ Ignite client and I
>>> need your advice. Mostly I'd like to hear from our users and
>>> those who are experienced in C++. Currently we have two
>>> versions of most API methods - the throwing one and the
>>> one that returns error through output argument. This was initially
>>> done because we were not sure which way of error-reporting
>>> is going to be preferred by our users.
>>>
>>> Now this approach bloats C++ API a lot and makes it harder to
>>> maintain and optimize code. I propose like to abandon and deprecate
>>> non-throwing version of API and only leave throwing version,
>>> but first I want to hear from you guys - what do you think? Does
>>> anyone use non-throwing version of the API? Maybe your toolchain
>>> does not support exceptions or are you disabling them on purpose?
>>>
>>> For those who prefer disabling exceptions I propose to introduce
>>> some macros like IGNITE_DISABLE_EXCEPTIONS and add
>>> some thread-local error-storing mechanism like ignite::GetLastError().
>>>
>>> What do you guys think?
>>>
>>> Best Regards,
>>> Igor
>>>
>>
>
>

[Igor Sapego]

I've read through the old discussion. It seems that I was not yet
a part of the community back there thats why I could not find it.

Denis, error code approach is more a C way, not C++. In most
cases C++ developers avoid exceptions in embedded development,
in legacy applications where it is hard to introduce exception safety,
or/and if their compiler is old, as old compilers had significant
overhead when used with exceptions and thus had exceptions
disabled by default.

However, most applications now use modern compilers with
zero-cost exceptions implementation and actively use standard
library, which uses exceptions for error reporting anyway.

Best Regards,
Igor

On Tue, Jan 24, 2017 at 10:49 AM, Vladimir Ozerov <[hidden email]>
wrote:

> Originally I tried to cover situation when user disabled exceptions. In
> this case throwing something will lead to application crash. However, for
> now I believe that such use case is not very likely as Ignite is relatively
> high-level product. For this reason I would prefer to keep clean and
> compact API which will throw exceptions. But still have a workaround for
> users which do not want that. For instance, we may consult to some
> environment variable in runtime, or to some preprocessor flag in compile
> time, and expose additional static "GetLastError" method.
>
> On Mon, Jan 23, 2017 at 11:35 PM, Denis Magda <[hidden email]> wrote:
>
> > Guys,
> >
> > I found the initial discussion from the early times of our C++ client:
> > http://apache-ignite-developers.2346864.n4.nabble.
> > com/C-exception-handling-strategy-td778.html
> >
> > Vovan, that time you were on the side of error-code methods. Why have you
> > changed you mind proposing to make the throwing version default one? Any
> > new tendency in C++ community?
> >
> > —
> > Denis
> >
> > On Jan 23, 2017, at 2:56 AM, Vladimir Ozerov <[hidden email]>
> wrote:
> >
> > +1 to Igor's idea. Ignite is relatively high-level product and we do not
> > expect ultra-optimized users who cannot allow exceptions to be enabled.
> > Macros should be a good workaround for them, though.
> >
> > On Sat, Jan 21, 2017 at 6:47 PM, Denis Magda <[hidden email]>
> wrote:
> >
> >> Hi Igor,
> >>
> >> My C++ experience is based only on error code methods. This is why I
> >> thought that exceptions based approach is unrelated to C++ at all.
> >>
> >> I do remember we discussed all the pros and cons of these ways before.
> >> Could you find that old discussion and share it here? I'm on a mobile
> now,
> >> not easy to do on my own.
> >>
> >> Denis
> >>
> >>
> >> On Friday, January 20, 2017, Igor Sapego <[hidden email]> wrote:
> >>
> >>> Hi Igniters,
> >>>
> >>> I'm the guy who mostly contribute in C++ Ignite client and I
> >>> need your advice. Mostly I'd like to hear from our users and
> >>> those who are experienced in C++. Currently we have two
> >>> versions of most API methods - the throwing one and the
> >>> one that returns error through output argument. This was initially
> >>> done because we were not sure which way of error-reporting
> >>> is going to be preferred by our users.
> >>>
> >>> Now this approach bloats C++ API a lot and makes it harder to
> >>> maintain and optimize code. I propose like to abandon and deprecate
> >>> non-throwing version of API and only leave throwing version,
> >>> but first I want to hear from you guys - what do you think? Does
> >>> anyone use non-throwing version of the API? Maybe your toolchain
> >>> does not support exceptions or are you disabling them on purpose?
> >>>
> >>> For those who prefer disabling exceptions I propose to introduce
> >>> some macros like IGNITE_DISABLE_EXCEPTIONS and add
> >>> some thread-local error-storing mechanism like ignite::GetLastError().
> >>>
> >>> What do you guys think?
> >>>
> >>> Best Regards,
> >>> Igor
> >>>
> >>
> >
> >
>

[Pavel Tupitsyn]

+1 for ditching non-throwing methods.

On Tue, Jan 24, 2017 at 2:01 PM, Igor Sapego <[hidden email]> wrote:

> I've read through the old discussion. It seems that I was not yet
> a part of the community back there thats why I could not find it.
>
> Denis, error code approach is more a C way, not C++. In most
> cases C++ developers avoid exceptions in embedded development,
> in legacy applications where it is hard to introduce exception safety,
> or/and if their compiler is old, as old compilers had significant
> overhead when used with exceptions and thus had exceptions
> disabled by default.
>
> However, most applications now use modern compilers with
> zero-cost exceptions implementation and actively use standard
> library, which uses exceptions for error reporting anyway.
>
> Best Regards,
> Igor
>
> On Tue, Jan 24, 2017 at 10:49 AM, Vladimir Ozerov <[hidden email]>
> wrote:
>
>> Originally I tried to cover situation when user disabled exceptions. In
>> this case throwing something will lead to application crash. However, for
>> now I believe that such use case is not very likely as Ignite is
>> relatively
>> high-level product. For this reason I would prefer to keep clean and
>> compact API which will throw exceptions. But still have a workaround for
>> users which do not want that. For instance, we may consult to some
>> environment variable in runtime, or to some preprocessor flag in compile
>> time, and expose additional static "GetLastError" method.
>>
>> On Mon, Jan 23, 2017 at 11:35 PM, Denis Magda <[hidden email]> wrote:
>>
>> > Guys,
>> >
>> > I found the initial discussion from the early times of our C++ client:
>> > http://apache-ignite-developers.2346864.n4.nabble.
>> > com/C-exception-handling-strategy-td778.html
>> >
>> > Vovan, that time you were on the side of error-code methods. Why have
>> you
>> > changed you mind proposing to make the throwing version default one? Any
>> > new tendency in C++ community?
>> >
>> > —
>> > Denis
>> >
>> > On Jan 23, 2017, at 2:56 AM, Vladimir Ozerov <[hidden email]>
>> wrote:
>> >
>> > +1 to Igor's idea. Ignite is relatively high-level product and we do not
>> > expect ultra-optimized users who cannot allow exceptions to be enabled.
>> > Macros should be a good workaround for them, though.
>> >
>> > On Sat, Jan 21, 2017 at 6:47 PM, Denis Magda <[hidden email]>
>> wrote:
>> >
>> >> Hi Igor,
>> >>
>> >> My C++ experience is based only on error code methods. This is why I
>> >> thought that exceptions based approach is unrelated to C++ at all.
>> >>
>> >> I do remember we discussed all the pros and cons of these ways before.
>> >> Could you find that old discussion and share it here? I'm on a mobile
>> now,
>> >> not easy to do on my own.
>> >>
>> >> Denis
>> >>
>> >>
>> >> On Friday, January 20, 2017, Igor Sapego <[hidden email]> wrote:
>> >>
>> >>> Hi Igniters,
>> >>>
>> >>> I'm the guy who mostly contribute in C++ Ignite client and I
>> >>> need your advice. Mostly I'd like to hear from our users and
>> >>> those who are experienced in C++. Currently we have two
>> >>> versions of most API methods - the throwing one and the
>> >>> one that returns error through output argument. This was initially
>> >>> done because we were not sure which way of error-reporting
>> >>> is going to be preferred by our users.
>> >>>
>> >>> Now this approach bloats C++ API a lot and makes it harder to
>> >>> maintain and optimize code. I propose like to abandon and deprecate
>> >>> non-throwing version of API and only leave throwing version,
>> >>> but first I want to hear from you guys - what do you think? Does
>> >>> anyone use non-throwing version of the API? Maybe your toolchain
>> >>> does not support exceptions or are you disabling them on purpose?
>> >>>
>> >>> For those who prefer disabling exceptions I propose to introduce
>> >>> some macros like IGNITE_DISABLE_EXCEPTIONS and add
>> >>> some thread-local error-storing mechanism like ignite::GetLastError().
>> >>>
>> >>> What do you guys think?
>> >>>
>> >>> Best Regards,
>> >>> Igor
>> >>>
>> >>
>> >
>> >
>>
>
>

[dmagda]

Thanks for the explanation. Support your intention than, let’s make the exceptions-based approach default one and leave an ability to fallback to error-codes if required.

—
Denis

> On Jan 24, 2017, at 3:01 AM, Igor Sapego <[hidden email]> wrote:
>
> I've read through the old discussion. It seems that I was not yet
> a part of the community back there thats why I could not find it.
>
> Denis, error code approach is more a C way, not C++. In most
> cases C++ developers avoid exceptions in embedded development,
> in legacy applications where it is hard to introduce exception safety,
> or/and if their compiler is old, as old compilers had significant
> overhead when used with exceptions and thus had exceptions
> disabled by default.
>
> However, most applications now use modern compilers with
> zero-cost exceptions implementation and actively use standard
> library, which uses exceptions for error reporting anyway.
>
> Best Regards,
> Igor
>
> On Tue, Jan 24, 2017 at 10:49 AM, Vladimir Ozerov <[hidden email] <mailto:[hidden email]>> wrote:
> Originally I tried to cover situation when user disabled exceptions. In
> this case throwing something will lead to application crash. However, for
> now I believe that such use case is not very likely as Ignite is relatively
> high-level product. For this reason I would prefer to keep clean and
> compact API which will throw exceptions. But still have a workaround for
> users which do not want that. For instance, we may consult to some
> environment variable in runtime, or to some preprocessor flag in compile
> time, and expose additional static "GetLastError" method.
>
> On Mon, Jan 23, 2017 at 11:35 PM, Denis Magda <[hidden email] <mailto:[hidden email]>> wrote:
>
> > Guys,
> >
> > I found the initial discussion from the early times of our C++ client:
> > http://apache-ignite-developers.2346864.n4.nabble <http://apache-ignite-developers.2346864.n4.nabble/>.
> > com/C-exception-handling-strategy-td778.html
> >
> > Vovan, that time you were on the side of error-code methods. Why have you
> > changed you mind proposing to make the throwing version default one? Any
> > new tendency in C++ community?
> >
> > —
> > Denis
> >
> > On Jan 23, 2017, at 2:56 AM, Vladimir Ozerov <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > +1 to Igor's idea. Ignite is relatively high-level product and we do not
> > expect ultra-optimized users who cannot allow exceptions to be enabled.
> > Macros should be a good workaround for them, though.
> >
> > On Sat, Jan 21, 2017 at 6:47 PM, Denis Magda <[hidden email] <mailto:[hidden email]>> wrote:
> >
> >> Hi Igor,
> >>
> >> My C++ experience is based only on error code methods. This is why I
> >> thought that exceptions based approach is unrelated to C++ at all.
> >>
> >> I do remember we discussed all the pros and cons of these ways before.
> >> Could you find that old discussion and share it here? I'm on a mobile now,
> >> not easy to do on my own.
> >>
> >> Denis
> >>
> >>
> >> On Friday, January 20, 2017, Igor Sapego <[hidden email] <mailto:[hidden email]>> wrote:
> >>
> >>> Hi Igniters,
> >>>
> >>> I'm the guy who mostly contribute in C++ Ignite client and I
> >>> need your advice. Mostly I'd like to hear from our users and
> >>> those who are experienced in C++. Currently we have two
> >>> versions of most API methods - the throwing one and the
> >>> one that returns error through output argument. This was initially
> >>> done because we were not sure which way of error-reporting
> >>> is going to be preferred by our users.
> >>>
> >>> Now this approach bloats C++ API a lot and makes it harder to
> >>> maintain and optimize code. I propose like to abandon and deprecate
> >>> non-throwing version of API and only leave throwing version,
> >>> but first I want to hear from you guys - what do you think? Does
> >>> anyone use non-throwing version of the API? Maybe your toolchain
> >>> does not support exceptions or are you disabling them on purpose?
> >>>
> >>> For those who prefer disabling exceptions I propose to introduce
> >>> some macros like IGNITE_DISABLE_EXCEPTIONS and add
> >>> some thread-local error-storing mechanism like ignite::GetLastError().
> >>>
> >>> What do you guys think?
> >>>
> >>> Best Regards,
> >>> Igor
> >>>
> >>
> >
> >
>