nothrow by default

[Johannes Pfau]

Am Sun, 05 Jan 2020 19:53:59 +0000 schrieb Ola Fosheim Grøstad:

> On Sunday, 5 January 2020 at 15:02:59 UTC, Johannes Pfau wrote:
>> This certainly needs to be considered, however: Some languages such as
>> go (server!) and C++ with std:error decided to go for error codes for
>> error handling.
> 
> What is "std::error"? If you mean "std::error_code" then it is for
> wrapping OS error codes like the ones from Unix. (You can throw it if
> want...)
> 

As far as I know, starting from C++11 std::error_code can be extended and 
has been used in newer updates to the C++ standard library instead of 
exceptions. (e.g. there is now a future error category). See https://
akrzemi1.wordpress.com/2017/07/12/your-own-error-code/

std::expected / boost outcome proposals are also related. There certainly 
is a trend away from exception to error-code like systems. But I have to 
admit, I don't know much about C++, so maybe those are bad / non-
representative examples.

> The error handling regime in Go is not something anyone should copy. The
> language lacks features that makes code maintainable over time. Lots of
> pointless error-handling boilerplate noise. Also, they didn't do it
> because of speed, Go is not that fast. They did it for no scientific
> reason, just their own (bad) taste,
> but they later found that they had to add the awful hack that resembles
> exceptions, but is a lot more ugly and clunky. Although you can hack it
> to do what you want, in a rather type-unsafe way.
> So I do that, but Go is the error handling scarecrow of modern
> languages... You don't want to write big programs in Go.
> 
> Go I useful for small web services because it has a decent runtime,
> stable language design, few compiler bugs, decent web-service libraries
> and cloud support. However, the language itself is pretty primitive (for
> no good reason).

That's probably true. Still, you can do a exception system with the same 
user facing API but without backtracing. So you get rid of unwind tables 
and the backtrace support code making the failure case faster while 
reducing the performance of the succes case. In that case the only 
question is whether the performance difference is important for some 
applications.

Of course, ideally which backend implementation is used could be an 
implementation detail.

-- 
Johannes