I feel like you're missing the whole point, here. An interface that is extremely hard to use correctly without turning small bugs into major outages is not a good tool.
And one way to make sure this doesn't happen is to write exception-safe code, because Go has exceptions.
You could also argue that your C++ code shouldn't throw, and I agree. It should very rarely throw. But when it does it should be safe.
If Go had simply not had exceptions then this would have been easier.
> It's called panic in Go so panicking should be hopefully rare for the peace of mind
If you write a web service that hits a bug that panics about once per million requests, and you run 1000 qps, that means your Lock();dothing;Unlock() will deadlock the whole webserver once every 15 minutes.
If you write exception safe code, then it does not.
Uhm… no… no they should not.
I feel like you're missing the whole point, here. An interface that is extremely hard to use correctly without turning small bugs into major outages is not a good tool.
And one way to make sure this doesn't happen is to write exception-safe code, because Go has exceptions.
You could also argue that your C++ code shouldn't throw, and I agree. It should very rarely throw. But when it does it should be safe.
If Go had simply not had exceptions then this would have been easier.
> It's called panic in Go so panicking should be hopefully rare for the peace of mind
If you write a web service that hits a bug that panics about once per million requests, and you run 1000 qps, that means your Lock();dothing;Unlock() will deadlock the whole webserver once every 15 minutes.
If you write exception safe code, then it does not.