ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: Abandon of the non-throwing version of C++ client API
Date Tue, 24 Jan 2017 11:06:20 GMT
+1 for ditching non-throwing methods.

On Tue, Jan 24, 2017 at 2:01 PM, Igor Sapego <isapego@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>
> 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> 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 <vozerov@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>
>> 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> 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
>> >>>
>> >>
>> >
>> >
>>
>
>

Mime
View raw message