Exceptions won't be missed at all, with or without generic programming, because, and I get tired of saying this, Go has exceptions. panic/recover/defer provide all the functionality of raise/catch/finally -- the main difference in structure being that (1) the context is always a function, not some other block within a function, and, (2) "recover" is done within a deferred function (loosely parallel to an "finally" block) as opposed to "catch" which is done in a sibling block to "finally". [1]
Defer is basically finally without block structure, triggered instead by the popping of the surrounding procedural call context. So instead of a block, you have to create a new function instead to unwind...how is the extra complexity of avoiding simple block structure worth it?
And what is the equivalent of catch if we have an equivalent of finally? It seems to be recover, which allows a deferred execution to query what exception has occurred, correct? Is there a good discussion of why this is better than try/catch/finally?
> Defer is basically finally without block structure, triggered instead by the popping of the surrounding procedural call context. So instead of a block, you have to create a new function instead to unwind...how is the extra complexity of avoiding simple block structure worth it?
How is function structure any more complex than block structure?(I mean, visually, sure, there are potentially a few extra sigils, but structurally how is a block different than a nullary function?)
> And what is the equivalent of catch if we have an equivalent of finally?
Recover within a deferred function provides the ability to do the functionality of catch -- I wouldn't call it a one-for-one equivalent (the combination of features is equivalent, but there isn't a one-for-one correspondence between the individual features except between panic and raise/throw.)
Thank you. I'd still like to know why this is better and not just different. Or is there some legacy design I'm missing, like in one of Rob Pike's previous languages?
> I'd still like to know why this is better and not just different.
Its potentially more flexible, in that it doesn't restrict the "generic" cleanup code to run strictly after the exception handling code; this also probably makes things a bit more clear in the instances where you want to apply logic in the guaranteed-closeout that might affect return values but needs to consider errors in the event they occurred.
Exceptions won't be missed at all, with or without generic programming, because, and I get tired of saying this, Go has exceptions. panic/recover/defer provide all the functionality of raise/catch/finally -- the main difference in structure being that (1) the context is always a function, not some other block within a function, and, (2) "recover" is done within a deferred function (loosely parallel to an "finally" block) as opposed to "catch" which is done in a sibling block to "finally". [1]
> So panic is basically an exception
Yes.
> but in callback form rather than block form
No.
[1] see: http://blog.golang.org/defer-panic-and-recover