Make exceptions optional

[JakeSays]

It would be great if this library could be used without exceptions. There are many environments where exceptions are not allowed.

[fpagliughi]

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:

1. Constructors that detect errors
2. Functions that just return a success value (and throw on error)

[ldgeng]

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:

1. Constructors that detect errors
2. Functions that just return a success value (and throw on error)

std::error_code?

[ldgeng]

just like winapi

[fpagliughi]

std::error_code?

Wowwwww... I had no idea that was even in there!. I'll definitely have a look at that. Thanks, @ldgeng.

[fpagliughi]

just like winapi

@ldgeng Can you point me to the winapi code that uses std::error_code?

[fpagliughi]

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:

• Get rid of exceptions.
• Use std::error_code (for all errors)

[JakeSays]

@fpagliughi hey this is perfect!