You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
http_exception Should Derive from std::runtime_error
First of all, I want to say thank you for creating such an outstanding library. The cpprestsdk is a comprehensive toolkit that offers a deep understanding of the components involved, especially in the C++ ecosystem.
While working with the library, I noticed an area that could be improved. In my projects, I typically separate exceptions into different categories, such as runtime errors and logic errors. This helps me handle them more effectively. I was surprised to find that http_exception, which I believe falls under the runtime error category, wasn't caught by my existing exception-handling code.
Would it be possible to have http_exception derive from std::runtime_error? I believe this would align well with standard C++ practices and make it easier to integrate the library into existing projects. Are there any potential downsides or pitfalls to making this change?
Thank you for considering this suggestion, and I look forward to your thoughts.
The text was updated successfully, but these errors were encountered:
http_exception
Should Derive fromstd::runtime_error
First of all, I want to say thank you for creating such an outstanding library. The cpprestsdk is a comprehensive toolkit that offers a deep understanding of the components involved, especially in the C++ ecosystem.
While working with the library, I noticed an area that could be improved. In my projects, I typically separate exceptions into different categories, such as runtime errors and logic errors. This helps me handle them more effectively. I was surprised to find that
http_exception
, which I believe falls under the runtime error category, wasn't caught by my existing exception-handling code.Would it be possible to have
http_exception
derive fromstd::runtime_error
? I believe this would align well with standard C++ practices and make it easier to integrate the library into existing projects. Are there any potential downsides or pitfalls to making this change?Thank you for considering this suggestion, and I look forward to your thoughts.
The text was updated successfully, but these errors were encountered: