|
 |
http://blog.golang.org/2010/08/defer-panic-and-recover.html
How Go does exceptions and dispose/destructor/whatever stuff.
I am not sure I like it. :-) Seems like there's a fair number of drawbacks,
except with the benefit of the stuff being statements and functions rather
than control flow, meaning you can probably construct more general-purpose
stuff from it. (Altho not quite powerful enough to do that properly.)
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
|
|
|
Darren New <dne### [at] san rrcom> wrote:
> http://blog.golang.org/2010/08/defer-panic-and-recover.html
The 'defer' feature sounds a lot like reinventing the RAII mechanism,
the hard way.
Also, I can't really understand how 'panic' and 'recover' are different
from regular 'throw' and 'catch' in almost any other language.
--
- Warp
Post a reply to this message
|
|
|
|
Warp wrote:
> The 'defer' feature sounds a lot like reinventing the RAII mechanism,
> the hard way.
Worse in some ways, better in others. For example, I don't know any way to
use RAII to conditionally modify the return value of the function you're
returning from in the event of an error. Also, you can't run a destructor
inside an "if" statement - scopes nest statically, not dynamically.
On the other hand, if you *are* using it for resource management, you have
to remember to write it everywhere you allocate the resource. The solution
there, methinks, would be to put more resources under management.
Defer doesn't introduce a scope, so you can invoke it from inside a
conditional or a loop.
On the other hand, defer always runs at the end of the function in which it
was called, so you can't use it easily inside a library function where you
want it to run when the method calling the library entrypoint returns.
Defer takes a lambda, so it can easily refer to local values from the
function that called it when it runs. You'd have to use pointers to autos
stored in the RAII class that get dereferenced in the destructor to do
something like that in C++.
> Also, I can't really understand how 'panic' and 'recover' are different
> from regular 'throw' and 'catch' in almost any other language.
Again, it's because they're not control flow statements. "panic" is pretty
much identical to "throw" except it confusingly looks like a function
instead of a statement, so you have special cases in the wrong place in the
compiler as it does control flow analysis. (I.e., in much the same way that
old C compilers might complain about a function that ends with "exit()"
inside a conditional not returning a value from that branch.)
Recover can be inside a conditional, just like defer can. On the other hand,
most variants of "catch" have something equivalent to "re-throw", so...
It's also not obvious to me that any sort of stack trace gets passed up, so
if you're trying to debug why it's panicing, it isn't clear to me you can
manage that. I suspect once you "recover" a panic, you're pretty much
screwed in terms of debugging if you recovered a panic you didn't expect.
Everything I see about Go convinces me they haven't looked at what's already
out there and they haven't learned from what people have already written and
they haven't really thought about all the use cases for the features they're
"reinventing" like this. Maybe it's great for what google does, but it
doesn't seem like the general-purpose system language it's hyped as.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
|
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > Also, I can't really understand how 'panic' and 'recover' are different
> > from regular 'throw' and 'catch' in almost any other language.
> Again, it's because they're not control flow statements.
Hmm, I'm not sure I would call 'throw' and 'catch' control flow
statements per se...
--
- Warp
Post a reply to this message
|
|
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> Also, I can't really understand how 'panic' and 'recover' are different
>>> from regular 'throw' and 'catch' in almost any other language.
>
>> Again, it's because they're not control flow statements.
>
> Hmm, I'm not sure I would call 'throw' and 'catch' control flow
> statements per se...
"throw" is a control flow statement because the compiler can tell that the
following statements don't get executed.
int xyz() { throw "Nope!"; }
The compiler should be able to suppress the warning that you're falling off
the end of the function without returning a value.
Catch is certainly a control flow statement. It even introduces a new scope,
it switches based on the class of the exception (if any) that it catches, etc.
try { do_something(); }
catch (IOException e) { alpha(); }
catch (NullPointerException e) { beta(); }
catch (MemoryException e) { gamma(); }
I'm not sure how that wouldn't count as control flow if "switch" does?
The way "catch" differs from "recover" (for example) is that there's no way
to do the equivalent of
func xyz(i int)
{
if (i < 24) recover();
}
In a language with throw and catch, there's no way to run
"do_something_that_might_panic()" without catching the value and then
rethrowing it if you don't want it.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
|
