+1 for ditching non-throwing methods. On Tue, Jan 24, 2017 at 2:01 PM, 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]> > 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]> 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 <[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]> >> 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]> 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 >> >>> >> >> >> > >> > >> > >
