Strange timeout bug. about async HOT 10 CLOSED

To me it seems like a bug. If there is an exception, i need to be able to catch it.
But I do not mind using something different. Fiber.scheduler.raise is a hack anyway.

My goal is to be able to stop a Fiber from another Fiber.
(If possible using the ruby built in methods, to be compatible with other Fiber scheduler implementations)
And I still do not know how to do it. See #263

from async.

Am I doing something wrong?

A rescue without an explicit exception class will only catch exceptions that are descendants of StandardError. In your example, MyException is a descendant of Exception, which is the lowest-level exception class. To be able to rescue your exception, you can do any of the following:

• rescue MyException => e - which will rescue only MyException
• rescue Exception => e - which will rescue all exceptions
• define the custom exception as class MyException < StandardError

from async.

Sorry my family has been sick I have not had time to review this issue.

from async.

@noteflakes

Yep, that was it. Not a bug at all then, just rescue behaving differently than I expected. Tyvm.

from async.

Thanks for the solution!
Usually i do not find such surprises using ruby.
Do you know why ruby behaves this way?

from async.

Thanks, if possible, are you able to make a MVP failing test case as a PR? This will help me greatly.

from async.

I am confused, here is a shorter version:

require 'async'

Fiber.set_scheduler(Async::Scheduler.new)

class MyException < Exception
end

@fiber = Fiber.schedule do
  begin
    sleep 1
  rescue => e
    puts e.inspect
  end
end

Fiber.schedule do
  sleep 0.1
  Fiber.scheduler.raise(@fiber, MyException)
end

Am I doing something wrong?

from async.

The output of the above snippet is:

/Users/thomas/.sandbox/lib/ruby/gems/3.2.0/gems/async-2.6.3/lib/async/scheduler.rb:132:in `transfer': MyException (MyException)
	from /Users/thomas/.sandbox/lib/ruby/gems/3.2.0/gems/async-2.6.3/lib/async/scheduler.rb:132:in `block'
	from /Users/thomas/.sandbox/lib/ruby/gems/3.2.0/gems/async-2.6.3/lib/async/scheduler.rb:154:in `kernel_sleep'
	from -:10:in `sleep'
	from -:10:in `block in <main>'
	from /Users/thomas/.sandbox/lib/ruby/gems/3.2.0/gems/async-2.6.3/lib/async/task.rb:160:in `block in run'
	from /Users/thomas/.sandbox/lib/ruby/gems/3.2.0/gems/async-2.6.3/lib/async/task.rb:330:in `block in schedule'

I can create a PR for this and @ all involved if you'd like. It looks like Fiber.scheduler.raise(@fiber, MyException) passes down to Fiber#raise on @fiber, so you could also probably shorten that line to simply @fiber.raise(MyException) as I believe Fiber#raise is the intended way to raise a Fiber level exception. I've confirmed that the output is the same.

Regarding the issue itself, while the backtrace notes where the Fiber is currently blocking, I'm not sure if an externally raised exception is bound by that scope, so I'm not sure if you're supposed to be able to catch it this way.

from async.

It gets weirder, oddly enough. Your example works just fine the moment you remove the custom exception class. It turns out the fact that the caller is a Fiber might not even be relevant.

This cannot be caught:

require 'async'

Fiber.set_scheduler(Async::Scheduler.new)

class CustomException < Exception
end

fibera = Fiber.schedule do
  begin
    sleep 5
  rescue => e
    puts("exception caught")
  end
end

Fiber.scheduler.raise(fibera, CustomException)

This can, and outputs "exception caught":

require 'async'

Fiber.set_scheduler(Async::Scheduler.new)

fibera = Fiber.schedule do
  begin
    sleep 5
  rescue => e
    puts("exception caught")
  end
end

Fiber.scheduler.raise(fibera, RuntimeError)

I'm using Ruby 3.2. I can create the PR if you'd like. Asking because I'm not the OP.

from async.

Do you know why ruby behaves this way?

This design allows lower-level exceptions, such as Interrupt and SystemExit (which are raised on SIGINT and SIGTERM signals respectively) to propagate to the top-level and be handled centrally by either custom app code or Ruby's default handlers.

from async.