I want off Mr. Golang's Wild Ride

[Ali Çehreli]

On 3/1/20 3:47 AM, Ola Fosheim Grøstad wrote:

 > True, did you also adopt the very noisy Go-pattern of manually
 > propagating all errors or did you use their ad-hoc take on "exceptions"?

We used C-like error propagation, which was not bullet-proof: There were 
a few bugs related to propogation mistakes. (I think by simply 
forgetting to check or propagating the err variable from an outer scope, 
etc. I don't remember now.)

I don't even know what ad-hoc Go exceptions are. :)

 > (I personally feel that the lack of proper exceptions is more of a
 > problem than generics.)

I agree but there is so much talk these days on the cost on exceptions 
especially in the C++ world[1][2] that I didn't want to open that topic. 
:) Additionally, exceptions are banned in safety-critical embedded 
sytems[3]; so, even though I find exceptions very useful, I started to 
have doubts on the topic.

Ali

[1] Herb Sutter: https://www.youtube.com/watch?v=os7cqJ5qlzo

[2] 
https://www.research.ed.ac.uk/portal/files/78829292/low_cost_deterministic_C_exceptions_for_embedded_systems.pdf

[3] One problem I learned last year was the fact that even though there 
can be one exception in flight, there can be unlimited number of 
exception objects that are in caught but not yet destroyed state:

try (foo()) {
   // ...
} catch (const Exception & e) {
   bar();
}

bar() may throw and handle another exception, which would normally be 
fine. However, note that 'e' of this block is still alive until bar() 
returns, which means there can be unlimited number of objects, which 
does not fit with "allocate all your memory up front" philosophy of some 
embedded systems. This was news to me until the end of last year.