Rescue in __define_method_with_matching__ obscures execution errors
beezee opened this issue · comments
If I call something from a matched fn that triggers a NoMethodError or an ArgumentError, this is obscured by the rescue block here.
Even though the matched fn was found and executed, I'm given an exception that says otherwise, and the original error is obscured.
One option would be to tack original error onto the caught one for debug. Better would be to rescue around match, but not around execution of matched method.
Happy to open a PR for this if it's something you'd review and merge.
Link to code in question - https://github.com/jdantonio/functional-ruby/blob/master/lib/functional/pattern_matching.rb#L130
@beezee That sounds like a great idea. I'd be happy to merge a PR!
Do you have any other suggestions? Most of my available time for side-projects is going to concurrent-ruby but I'd love to see this gem grow. I'm open to all suggestions.
Great I'll try to get something together this weekend.
I did find something else I'd like to see, but I'll open another issue for that.
@jdantonio Could you please clarify the idea behind that rescue from NoMethodError, ArgumentError, it seems that there is NoMethodError in case of missing super and ArgumentError in case of self.instance_exec(*argv, &match.body) failure is that correct, or there is some other cases?
btw, one more question, what do you think about changing your implementation of pattern matching with one from https://github.com/k-tsj/pattern-match? It will allow to use same pattern syntax in method definitions and as a standalone parts, also it seems to have more features.
@beezee @jdantonio news about this PR?
@cvb @lucasas I apologize for taking a few days to respond. I've been very busy working on the 1.0 release of concurrent-ruby.
I don't know the answer to the first question about NoMethodError and ArgumentError in pattern matching. It's been a very long time since I wrote that code and it's pretty complex. It's possible that I made a mistake. I'll look at it ASAP.
@cvb Please clarify your second question regarding the implementation from k-tsj. I don't think there are any namespace collisions between the two so you should be able to use both gems in the same project. I don't have a strong emotional attachment to my implementation so I'm open to changing it. Are you suggesting that we copy the code from that gem into this one?
@cvb Please clarify your second question regarding the implementation from k-tsj. I don't think there are any namespace collisions between the two so you should be able to use both gems in the same project. I don't have a strong emotional attachment to my implementation so I'm open to changing it. Are you suggesting that we copy the code from that gem into this one?
No there is no collisions at all, I can use both libs, I just don't like to have different pattern matching syntax when using defn and when using match from k-tsj implementation. So I thought about adding https://github.com/k-tsj/pattern-match as a dependency, and use it when defining defn methods, but I'm not completely sure about it, just thoughts.
I don't know the answer to the first question about NoMethodError and ArgumentError in pattern matching. It's been a very long time since I wrote that code and it's pretty complex. It's possible that I made a mistake. I'll look at it ASAP.
Thanks, that would be great, because code is complex. And if my guess is correct then I thought about removing ArgumentError catching and check arity of pattern and block by hands. And also raise NoMethodError when there is no match and no super method. This will allow to throw this errors from defn block without messing with implementation of defn. Will try to make pull request, maybe next week, to show what I exactly mean.
@jdantonio @lucasas guys, please have a look #27
should be fixed in v1.3.0-rc1
Do we need an RC, or should we just do a 1.3.0 release?
I want to fix docs before release