support re-raising exceptions when shutting down a timertask

[grosser]

I want to use a timer-task to execute a heartbeat function while some other code is running I was hoping shutdown would re-raise any exception that occurred inside the timer, but that seems to not be the case I saw that an observer could do that, but it adds a lot of complexity. It would be nice it a failed timer could re-raise it's exception when it's shut down without needed an observer, something like:

      task = Concurrent::TimerTask.execute(execution_interval: 10 * 60, run_now: true) do
        do_stuff
      end
      yield
    ensure
      task.shutdown reraise: true
    end

* Operating system:                mac
* Ruby implementation:             Ruby
* `concurrent-ruby` version:       1.1.10
* `concurrent-ruby-ext` installed: no
* `concurrent-ruby-edge` used:     no

[eregon]

How would that work if do_stuff is called multiple times and raises multiple times an exception?

[grosser]

It would reraise the last exception ... Or stop at the first exception and wait for shutdown call

On Mon, Jan 16, 2023, 11:30 AM Benoit Daloze @.***> wrote:

How would that work if do_stuff is called multiple times and raises multiple times an exception?

— Reply to this email directly, view it on GitHub https://github.com/ruby-concurrency/concurrent-ruby/issues/984#issuecomment-1384470890, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACYZ3RFR3GTWFKIDBWI7LWSWOVNANCNFSM6AAAAAAT5BMXQM . You are receiving this because you authored the thread.Message ID: @.***>

[eregon]

Or stop at the first exception and wait for shutdown call

That's not compatible with the fault tolerance of https://ruby-concurrency.github.io/concurrent-ruby/master/Concurrent/TimerTask.html

Last exception could be possible, but is it so hard to use an Observer? I'm not a big fan of adding complexity in the codebase if it can already be done reasonably simply another way.

[grosser]

yeah true, was mostly hoping it would be a good fit, thx for the details