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