+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 >> >
