You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Igor Sapego <is...@gridgain.com> on 2017/01/20 17:24:46 UTC
Abandon of the non-throwing version of C++ client API
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
Re: Abandon of the non-throwing version of C++ client API
Posted by Pavel Tupitsyn <pt...@apache.org>.
+1 for ditching non-throwing methods.
On Tue, Jan 24, 2017 at 2:01 PM, Igor Sapego <is...@gridgain.com> 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 <vo...@gridgain.com>
> 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 <dm...@apache.org> 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 <vo...@gridgain.com>
>> 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 <dm...@gridgain.com>
>> 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 <is...@gridgain.com> 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
>> >>>
>> >>
>> >
>> >
>>
>
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Pavel Tupitsyn <pt...@apache.org>.
+1 for ditching non-throwing methods.
On Tue, Jan 24, 2017 at 2:01 PM, Igor Sapego <is...@gridgain.com> 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 <vo...@gridgain.com>
> 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 <dm...@apache.org> 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 <vo...@gridgain.com>
>> 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 <dm...@gridgain.com>
>> 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 <is...@gridgain.com> 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
>> >>>
>> >>
>> >
>> >
>>
>
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Igor Sapego <is...@gridgain.com>.
Hi Alexander,
Ignite provides C++ API so it can't really be used by C clients anyway.
If we talk about simultaneous usage of libs/binaries compiled with the
different versions of compiler, I believe this is something that user
should not do anyway when they use libs with C++ API, as this may
lead to many issues beside exception handling.
Best Regards,
Igor
On Tue, Jan 31, 2017 at 10:59 AM, afedotov <al...@gmail.com>
wrote:
> Hi Igniters,
>
> One point we need to consider with exceptions approach is that throwing
> exceptions across shared library borders has many implications.
> For example, compiler version compatibility between libs and clients, the
> way libstdc++ in Linux or CRT in Windows is linked and others.
> But still, I suppose if we are not considering plain C clients then
> exceptions approach have its way to go.
>
> On Tue, Jan 24, 2017 at 11:43 PM, Denis Magda-2 [via Apache Ignite Users]
> <[hidden email] <http:///user/SendEmail.jtp?type=node&node=10327&i=0>>
> wrote:
>
>> 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]
>> <http:///user/SendEmail.jtp?type=node&node=10231&i=0>> 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]
>> <http:///user/SendEmail.jtp?type=node&node=10231&i=1>> 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]
>>> <http:///user/SendEmail.jtp?type=node&node=10231&i=2>> 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]
>>> <http:///user/SendEmail.jtp?type=node&node=10231&i=3>> 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]
>>> <http:///user/SendEmail.jtp?type=node&node=10231&i=4>> 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]
>>> <http:///user/SendEmail.jtp?type=node&node=10231&i=5>> 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
>>> >>>
>>> >>
>>> >
>>> >
>>>
>>
>>
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://apache-ignite-users.70518.x6.nabble.com/Abandon-of-
>> the-non-throwing-version-of-C-client-API-tp10157p10231.html
>> To start a new topic under Apache Ignite Users, email [hidden email]
>> <http:///user/SendEmail.jtp?type=node&node=10327&i=1>
>> To unsubscribe from Apache Ignite Users, click here.
>> NAML
>> <http://apache-ignite-users.70518.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
>
> --
> Kind regards,
> Alexander.
>
> ------------------------------
> View this message in context: Re: Abandon of the non-throwing version of
> C++ client API
> <http://apache-ignite-users.70518.x6.nabble.com/Abandon-of-the-non-throwing-version-of-C-client-API-tp10157p10327.html>
> Sent from the Apache Ignite Users mailing list archive
> <http://apache-ignite-users.70518.x6.nabble.com/> at Nabble.com.
>
Re: Abandon of the non-throwing version of C++ client API
Posted by afedotov <al...@gmail.com>.
Hi Igniters,
One point we need to consider with exceptions approach is that throwing
exceptions across shared library borders has many implications.
For example, compiler version compatibility between libs and clients, the
way libstdc++ in Linux or CRT in Windows is linked and others.
But still, I suppose if we are not considering plain C clients then
exceptions approach have its way to go.
On Tue, Jan 24, 2017 at 11:43 PM, Denis Magda-2 [via Apache Ignite Users] <
ml-node+s70518n10231h95@n6.nabble.com> wrote:
> 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]
> <http:///user/SendEmail.jtp?type=node&node=10231&i=0>> 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]
> <http:///user/SendEmail.jtp?type=node&node=10231&i=1>> 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]
>> <http:///user/SendEmail.jtp?type=node&node=10231&i=2>> 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]
>> <http:///user/SendEmail.jtp?type=node&node=10231&i=3>> 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]
>> <http:///user/SendEmail.jtp?type=node&node=10231&i=4>> 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]
>> <http:///user/SendEmail.jtp?type=node&node=10231&i=5>> 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
>> >>>
>> >>
>> >
>> >
>>
>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-users.70518.x6.nabble.com/Abandon-
> of-the-non-throwing-version-of-C-client-API-tp10157p10231.html
> To start a new topic under Apache Ignite Users, email
> ml-node+s70518n1h65@n6.nabble.com
> To unsubscribe from Apache Ignite Users, click here
> <http://apache-ignite-users.70518.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1&code=YWxleGFuZGVyLmZlZG90b2ZmQGdtYWlsLmNvbXwxfC0xMzYxNTU0NTg=>
> .
> NAML
> <http://apache-ignite-users.70518.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
Kind regards,
Alexander.
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Abandon-of-the-non-throwing-version-of-C-client-API-tp10157p10327.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Abandon of the non-throwing version of C++ client API
Posted by Denis Magda <dm...@apache.org>.
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 <is...@gridgain.com> 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 <vozerov@gridgain.com <ma...@gridgain.com>> 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 <dmagda@apache.org <ma...@apache.org>> 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 <vozerov@gridgain.com <ma...@gridgain.com>> 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 <dmagda@gridgain.com <ma...@gridgain.com>> 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 <isapego@gridgain.com <ma...@gridgain.com>> 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
> >>>
> >>
> >
> >
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Denis Magda <dm...@apache.org>.
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 <is...@gridgain.com> 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 <vozerov@gridgain.com <ma...@gridgain.com>> 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 <dmagda@apache.org <ma...@apache.org>> 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 <vozerov@gridgain.com <ma...@gridgain.com>> 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 <dmagda@gridgain.com <ma...@gridgain.com>> 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 <isapego@gridgain.com <ma...@gridgain.com>> 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
> >>>
> >>
> >
> >
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Igor Sapego <is...@gridgain.com>.
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 <vo...@gridgain.com>
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 <dm...@apache.org> 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 <vo...@gridgain.com>
> 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 <dm...@gridgain.com>
> 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 <is...@gridgain.com> 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
> >>>
> >>
> >
> >
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Igor Sapego <is...@gridgain.com>.
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 <vo...@gridgain.com>
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 <dm...@apache.org> 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 <vo...@gridgain.com>
> 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 <dm...@gridgain.com>
> 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 <is...@gridgain.com> 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
> >>>
> >>
> >
> >
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <dm...@apache.org> 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 <vo...@gridgain.com> 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 <dm...@gridgain.com> 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 <is...@gridgain.com> 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
>>>
>>
>
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <dm...@apache.org> 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 <vo...@gridgain.com> 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 <dm...@gridgain.com> 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 <is...@gridgain.com> 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
>>>
>>
>
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Denis Magda <dm...@apache.org>.
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 <vo...@gridgain.com> 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 <dmagda@gridgain.com <ma...@gridgain.com>> 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 <isapego@gridgain.com <ma...@gridgain.com>> 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
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Denis Magda <dm...@apache.org>.
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 <vo...@gridgain.com> 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 <dmagda@gridgain.com <ma...@gridgain.com>> 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 <isapego@gridgain.com <ma...@gridgain.com>> 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
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Vladimir Ozerov <vo...@gridgain.com>.
+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 <dm...@gridgain.com> 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 <is...@gridgain.com> 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
>>
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Vladimir Ozerov <vo...@gridgain.com>.
+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 <dm...@gridgain.com> 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 <is...@gridgain.com> 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
>>
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Denis Magda <dm...@gridgain.com>.
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 <is...@gridgain.com> 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
>
Re: Abandon of the non-throwing version of C++ client API
Posted by Denis Magda <dm...@gridgain.com>.
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 <is...@gridgain.com> 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
>