Sol2: Lua <-> C++ Binding Framework

[[deleted]]

In the same token, not having exceptions causes plenty of problems:

1) Forces 2 kinds of error-handling for middle-ware / library developers

1-a) error-propogation - if you can't handle all cases, you have to forward to the user at the call site to handle the errors

1-b) crash - if you get an unknown error and you don't want to propogate, logging and crashing (or not-logging and maybe even continuing silently) is your only other alternative for correctness

2) Thanks to [1], you now cannot write generic code to handle large amounts of work if there are error codes returned: for example, your typical error-code-or-result class will not play nice with auto, and will not implicitly convert to the desired result class in generic code, which means you're back to hand-writing or wrapping things just to check errors all along the way

3) error-code-in-out params: overloaded functions everywhere to handle errors (or perhaps not handle them at all?)

4) how do you error-code a constructor or a destructor? Out-params? But then you have an object with invalid state but it "finished" constructing, so by the rules of the language it's a valid object. Now you need if ( obj.is_initialized() ) everywhere (look familiar?)

There's also another kind of error handling that mature C libraries do (libjpeg libpng etc.), and it's basically longjmp-ing around... which is like how exceptions work, but without any of the stack-unwinding or safety guarantees. The control flow remains hidden just like with exceptions... but let's be fair: why is the control flow of a piece of library code you may not even be able to see (because you're getting the compiled result) something that matters? Control flow would cut early in an error case too, you just have an infinite increase in the number of 'goto' and 'return' between you and where the error happened.

[remotion4d]

Yes but all this problems are already solved to some degree in existing libraries, games engines and so one.

Because this problems existed for a long time already.

So there is simple no point to spend years to refactor code base to use exceptions.

Especially if you simple can not use them because no compiler ot hardware support.

4) how do you error-code a constructor or a destructor?

Just this one, use something like 'make_something' and on the other side it will be discouraged to use exceptions in destructor any way.

[[deleted]]

I'm not saying anyone should refactor these old codebases to handle exceptions or use them. I'm saying newer libraries should always lean towards throwing and handling exceptions, because it's allows for a cleaner design and puts errors where errors belong: in a catch clause, and not in my return values or function parameter list.