Closed JakeSays closed 1 year ago
Ironically, this library fell out of a bigger framework for embedded systems that specifically did not use exceptions or runtime type identification. Somehow, though, over the years, exceptions made their way into it.
I count only a handful in the whole library, so it wouldn't be a crazy amount of work. But how should we handle:
Ironically, this library fell out of a bigger framework for embedded systems that specifically did not use exceptions or runtime type identification. Somehow, though, over the years, exceptions made their way into it.
I count only a handful in the whole library, so it wouldn't be a crazy amount of work. But how should we handle:
- Constructors that detect errors
- Functions that just return a success value (and throw on error)
std::error_code?
just like winapi
std::error_code?
Wowwwww... I had no idea that was even in there!. I'll definitely have a look at that. Thanks, @ldgeng.
just like winapi
@ldgeng Can you point me to the winapi code that uses std::error_code?
Moving to std::error_code
would actually help with existing problems of platform error checks, and preset a road forward for TLS library error reporting. It also ties together a few other ideas. I am going to close this and move the conversation to Issue #77.
Please do comment on the ideas presented there. But, basically, it says "yes" to both of these ideas:
std::error_code
(for all errors)@fpagliughi hey this is perfect!
It would be great if this library could be used without exceptions. There are many environments where exceptions are not allowed.