-
Notifications
You must be signed in to change notification settings - Fork 27
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
Removed inappropriate $! reference in Net::FTP #24
Conversation
Net::FTP#transfercmd uses $! for error handling, so using Net::FTP in the rescue section will cause an unexpected data connection drop.
Thank you! @jeremyevans I've merged it, but tell me if something is wrong. |
@shugo it looks fine, except that it will not close the connection for non-StandardError exceptions. Maybe |
@jeremyevans Oh, I'll fix it. Thanks! |
I don't believe the merged fix is correct. There are flow control primitives like See also this discussion: https://bugs.ruby-lang.org/issues/18083 |
We could use a construction such as: begin
# ...
rescue Exception => e
raise
ensure
conn&.close if e
end @ioquatix do you think that is the best approach? |
There may be still a race codition when the thread is killed. t = Thread.start {
begin
sleep
rescue Exception => e
raise
ensure
p e
end
}
sleep(0.1)
t.kill How about the following code? succeeded = false
begin
# ...
succeeded = true
ensure
conn&.close if !succeeded
end |
The approach without rescue is fine if the You can use |
In https://bugs.ruby-lang.org/issues/15567 I discussed these types of problems, and I don't think there is any easy solution because not enough information is exposed. However, I think the proposed:
Is quite good. Ultimately what we want is something like:
I don't think we should implement some elaborate mechanism which checks the thread status etc. As I think that is a code smell. This is a common pattern and it should be easy to do the correct thing. |
(There is also an argument to be made that we shouldn't try to handle |
I've created a pull request: #27 It's may not be a perfect solution, but I also prefer the solution by the
The solution by the |
$!
in ensure section may be an Exception object that already exists before entering itsbegin
...end
.Net::FTP#transfercmd
uses$!
for error handling, so usingNet::FTP
in rescue section will cause an unexpected data connection drop. Since an exceptions is required to decide to close the data connection, it should be placed in rescue section.The reproduction code is as follows:
result: