3 ms·
"I'm not sure one really needs exceptions if you have goroutines, channels, and multiple return values. On the other hand, there are very compelling reasons for
by po 17y ago
"I'm not sure one really needs exceptions if you have goroutines, channels, and multiple return values. On the other hand, there are very compelling reasons for not having exceptions, given goroutines and channels."
I continually find exception handling to be a huge source of frustration; especially Java's checked exceptions. If I explicitly test for something in my method before calling another method, should I still have to catch, rethrow or declare that I throw its exception? If I don't check for the exceptional case first, then aren't I now using exceptions for flow control?
Unchecked exceptions seem a little more logical to me, but they still seem to cause disagreement on how they should be used.
The fact that they decided to put exception handling on hold here for now is really encouraging to me.
- Gupie 17y ago"there are very compelling reasons for not having exceptions, given goroutines and channels" This confuses me I would have thought the opposite would be true. The goroutine/channel concept seems Erlang like to me. Erlang uses exceptions, if a process crashes an exception is thrown to its parent which can then act appropriately. How does Go handle this, i.e. if a goroutine crashes who gets informed and how?
- stcredzero 17y agoI'm not sure there's always going to be a "parent."
- thenduks 17y agogoroutines are Erlang-like. Erlang doesn't have 'exceptions' though. In Erlang, if a process crashes (simulated or unexpectedly) it implicitly sends a specific message to it's parent. In Go you can emulate this by just checking for return values of stuff you do in the goroutine and send a similar message if it fails. The fact that Go is in early development here and I'd say this both could and will be improved in the future.