[FEATURE] REDIS_PLUS_PLUS_NO_EXCEPTIONS option?

[FrozenSource]

Is your feature request related to a problem? Please describe.
I love your work, but now I would like to use Redis in an exception-less application cause the back-end does not support it due to portability.

Describe the solution you'd like
I have considered other libraries for Redis but yours is the style I like and also the most feature complete.
I would love a passable REDIS_PLUS_PLUS_NO_EXCEPTIONS define which would pipe the exceptions to either a callback but preferably a return value. Even errno would be fine for existing APIs.

Describe alternatives you've considered
https://github.com/cpp-redis/cpp_redis , does exception-less operation but just not it if this would be considered.

Love to hear from you,

[sewenew]

Sorry, but the whole error system of redis-plus-plus is based on exception. It's a huge work to make it exception-less. I'll consider your suggestion, but I don't think it can be supported in the near future.

In your case, how about wrapping redis-plus-plus related code in a try {} catch (...) {} block, so that it never throws any exception outside the try-catch block?

Regards

[FrozenSource]

I understand it won't happen soon, and know it might be a big change but at least I let you know some might need it.

Some compiler targets of my application don't support try_catch at all at runtime... so both the try_catches in the library as well as the option of an abstraction is not possible unfortunately.

Thanks either way

[sewenew]

Thanks a lot for the suggestion!

By the way, what do you mean some compiler targets don't support try-catch at all at runtime? In that case, your application cannot even use STL containers, such as std::string, std::vector? Since these STL container might throw exceptions and they use try-catch in implementation. If that's the case, the whole stuff of redis-plus-plus need to redesigned, since it also depends heavily on STL.

Regards

[FrozenSource]

While it seems to change this year; for example WASM(+WASI) compilers and runtimes don't all support exception handling.
Next to the fact that try-catch gives a lot of overhead not all applications want. (Runtimes and whatnot)

While there are exceptions to the STL Containers... they are mostly allocation errors which would be unhandleable (and are normally not handled either like constructors), but in which cases an std::abort() is (to me) acceptable. Other than that, range checks can be done before accessing the container.
I have taken some look at your code but I don't think that it would be a problem depending on the behaviours you'd accept.

The STL libraries that I use being LLVM, gnu, and MSVC do have switches to not implement try-catch logic.

Regards

[sewenew]

Thanks for the info!

Regards