Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rescue mechanism design #605

Open
st0012 opened this issue Feb 27, 2018 · 5 comments

Comments

@st0012
Copy link
Member

commented Feb 27, 2018

I have some thought for the rescue keyword's scope:

We follow Ruby's design

In this implementation, we need to support these two cases:

def foo
  # do something
rescue StandardError
  # rescue!
end

# Or

def foo
  # do something
  begin
    # do other things
  rescue StandardError
    # rescue!
  end
end

Pros:

  • Lower the learning curve for Rubyists
  • More flexible

Cons:

  • The begin's scope might be difficult to control
  • I think this violates Goby's core concept, because in some cases both patterns works the same and users need to chose one of them.

We drop support the of begin keyword

This means we'll only able to use rescue like:

def foo
  # do something
rescue StandardError
  # rescue!
end

Pros:

  • Relatively easy to implement

Cons:

  • Lost flexibility, users can only chose rescue them all or not to rescue at all

Require begin for every rescue

def foo
  # do something
  begin
    # do other things
  rescue StandardError
    # rescue!
  end
end

Pros:

  • Easier to implement than implementing both types at the same time
  • Give users the flexibility

Cons:

  • Harder to implement than case 2
  • Can be verbose in some cases like
def foo
  begin
    # do other things
  rescue StandardError
    # rescue!
  end
end
@saveriomiroddi

This comment has been minimized.

Copy link
Member

commented Feb 27, 2018

I like the method Begin/End block inlining a lot:

def foo
  # code
rescue
  # code
ensure
  # code
end

so I think it should be implemented.

However, regarding the second case:

def foo
  begin; rescue; end # short version
end

I think it's not worth explicitly forbidding it, especially because B/E blocks can be placed at any level:

def foo
  if conditional
    begin; rescue; end
  end
end

and I think forbidding them a the root method level is somewhat arbitrary.

Also, I wish to mention that something I like a lot is B/E block inlining in Do/End blocks:

[].each do
  # code
rescue
  # rescue code
ensure
  # ensure code
end
@st0012

This comment has been minimized.

Copy link
Member Author

commented Feb 27, 2018

Ok, so it looks like I should first implement the begin version, and support the inlined version with some syntactic sugar

@ear7h

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2018

After looking through the code base, it seems like an entire function is compiled before execution. This means that the rescue statement can be 'registered' in the block scope during compilation and called, in the case of an error, during runtime. If this is the case, it seems like it seems like implementing the 2nd option wouldn't put us too far from properly implementing begin.

Although, one thing that'll take some work is keeping track of multiple rescue statements.

def foo(
    some_error()
    rescue ArgumentError
        # do stuff
    some_error()
    rescue ArgumentError
        # do other stuff
end
@st0012

This comment has been minimized.

Copy link
Member Author

commented Mar 4, 2018

@ear7h I don't think we'll support multiple rescue. In my opinion, if a method requires multiple rescue, it need to be refactored

@st0012 st0012 modified the milestones: version 0.1.8, test framework Mar 4, 2018

@ghost ghost added the in progress label Mar 4, 2018

@st0012

This comment has been minimized.

Copy link
Member Author

commented Mar 8, 2018

I gotta say this feature's complexity is higher than I expected. So I'll lower its priority, which means we need to build our test framework without rescuing mechanism. Is that ok? @saveriomiroddi

@st0012 st0012 removed this from the test framework milestone Mar 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.