Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] REDIS_PLUS_PLUS_NO_EXCEPTIONS option? #446

Open
FrozenSource opened this issue Jan 17, 2023 · 5 comments
Open

[FEATURE] REDIS_PLUS_PLUS_NO_EXCEPTIONS option? #446

FrozenSource opened this issue Jan 17, 2023 · 5 comments

Comments

@FrozenSource
Copy link

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
Copy link
Owner

sewenew commented Jan 19, 2023

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
Copy link
Author

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
Copy link
Owner

sewenew commented Jan 20, 2023

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
Copy link
Author

FrozenSource commented Jan 20, 2023

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
Copy link
Owner

sewenew commented Jan 22, 2023

Thanks for the info!

Regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants