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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > >> <mailto:[email protected]>> 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 > >>> > >> > > > > >
