Setting up an exception handler for every block invocation will be very expensive.
Setting up an exception handler for every block is *not* necessary -- only blocks with rescue clauses will have exception handling.
When I first saw a method def with a rescue I actually assumed that a rescue clause was supported for all block constructs. I wasn't until a couple of days later when I tried it on a if/end and it failed that I realized that it was a special case for method and class defs. Since then, I have often wished I could add rescue clauses to block structures that are currently do not support it.
I like adding optional rescue clauses to do/end but I think that rescue clauses should be supported on all syntax block constructs. I think that the same arguments for having rescue clauses on methods and class defs can be applied to having them on any block construct. And having the everywhere makes it easier to explain and think about (for me at least).
Peter
Peter: there's a problem with if and unless blocks and rescue clauses.
# this is valid code
begin
# do something
rescue
# if there's an exception
else # <---- uh-oh
# if there are no exceptions
end
See the `else' part? That would make if and unless blocks look odd:
if foo == bar
# do something
else
# do something else
rescue
# if there's an exception
else
# if there are no exceptions
end
Daniel Schierbeck
This should not apply to just do/end, but all *block* forms (which would exclude the if/unless syntax forms).
This should not apply to just do/end, but all *block* forms (which would exclude the if/unless syntax forms).
I agree with this and would love to see it. Good idea Daniel.
Brian
I'm in agreement about adding this to do..end ,and to the {..} form of block syntax as well.
The problem with priority of else in an if .. [ else] .. end is real but is a separate question.
Getting back to do..end
Notice that a block with just a single statement with a rescue modifier like:
x.call do
something_scary rescue something_not_so_scary
end
is legal, even though
x.call do
something_scare
rescue
something_not_so_scary
end
is not.
This makes me think that this is purely a syntactic restriction, and that there are no semantic arguments against this.
Rick DeNatale
Setting up an exception handler for every block is *not* necessary -- only blocks with rescue clauses will have exception handling.
When I first saw a method def with a rescue I actually assumed that a rescue clause was supported for all block constructs. I wasn't until a couple of days later when I tried it on a if/end and it failed that I realized that it was a special case for method and class defs. Since then, I have often wished I could add rescue clauses to block structures that are currently do not support it.
I like adding optional rescue clauses to do/end but I think that rescue clauses should be supported on all syntax block constructs. I think that the same arguments for having rescue clauses on methods and class defs can be applied to having them on any block construct. And having the everywhere makes it easier to explain and think about (for me at least).
Peter
Peter: there's a problem with if and unless blocks and rescue clauses.
# this is valid code begin # do something rescue # if there's an exception else # <---- uh-oh # if there are no exceptions endSee the `else' part? That would make if and unless blocks look odd:
if foo == bar # do something else # do something else rescue # if there's an exception else # if there are no exceptions endDaniel Schierbeck
This should not apply to just do/end, but all *block* forms (which would exclude the if/unless syntax forms).
I agree with this and would love to see it. Good idea Daniel.
Brian
I'm in agreement about adding this to do..end ,and to the {..} form of block syntax as well.
The problem with priority of else in an if .. [ else] .. end is real but is a separate question.
Getting back to do..end
Notice that a block with just a single statement with a rescue modifier like:
x.call do something_scary rescue something_not_so_scary endis legal, even though
x.call do something_scare rescue something_not_so_scary endis not.
This makes me think that this is purely a syntactic restriction, and that there are no semantic arguments against this.
Rick DeNatale