Can't trap exceptions

[rnhurt]

I'm writing a bot (using EventMachine + Sinatra) that listens to Jabber messages and responds to them. However, if Blather has a problem it bubbles up Exceptions that, for some reason, I cannot rescue. For example, if I try to connect to a non-existant server I get the following error and my program stops:

Blather::Stream::ConnectionFailed (Blather::Stream::ConnectionFailed)

I've tried putting begin...rescue around the @client.connect call but the error still gets thrown and my program stops. How do you trap these types of errors in Blather? Am I missing something obvious? I'm fairly new to EM so it might be something I'm not doing properly, but I've tried everything I can think of and nothing prevents this error (or any other Blather Exception) from calling EM.stop on the whole system. :(

[benlangfeld]

Can you please post a minimal test case that demonstrates the issue? That would make it far easier for me to get this fixed quickly.

[rnhurt]

This is as simple as I could get it. I would expect the EM.error_handler() to capture the Blather::Stream::ConnectionFailed exception but it doesn't. Am I doing something weird/wrong/stupid?

#!/usr/bin/env ruby
require "blather/client"

EM.error_handler { |e| puts " ******** #{e} " }

# Main program loop
EventMachine.run do
    jid = Blather::JID.new("[email protected]/Blather")
    @client = Blather::Client.setup(jid, "secret")
    @client.connect
end

[benlangfeld]

I'll take a look at this over the weekend.

[rnhurt]

Cool. I traced it back to the EM.event_callback method which has a couple of very interesting comments.

  def self.event_callback conn_binding, opcode, data # :nodoc:
    #
    # Changed 27Dec07: Eliminated the hookable error handling.
    # No one was using it, and it degraded performance significantly.
    # It's in original_event_callback, which is dead code.
    #
    # Changed 25Jul08: Added a partial solution to the problem of exceptions
    # raised in user-written event-handlers. If such exceptions are not caught,
    # we must cause the reactor to stop, and then re-raise the exception.
    # Otherwise, the reactor doesn't stop and it's left on the call stack.
    # This is partial because we only added it to #unbind, where it's critical
    # (to keep unbind handlers from being re-entered when a stopping reactor
    # runs down open connections). It should go on the other calls to user
    # code, but the performance impact may be too large.
    #

[rnhurt]

Clarification:

This issue is not just limited to a connection problem. Anytime Blather raises an exception it stops the whole program, the connection problem is just easiest to trigger. :)

[jsgoecke]

I have this same problem when attempting to capture SASL errors when there is an invalid username or password.

[d-mart]

Any ideas on this? I'm having the same issue. Restarting the process (as suggested in the flapjack issue above) is not possible for me since I have multiple XMPP client connections running in the same process.
The provided test case above accurately summarizes the problem for me too.

[benlangfeld]

#110 is my preferred solution to this and many other issues with Blather. Unfortunately, time is not easy to come by to fix it.

[emschwar]

Do you have any other suggestions for short-term workarounds besides restarts? All I can think of offhand is to subclass Blather::Client and override unbind to run

class MyClient < Blather::Client
  def unbind
    begin
      super
    rescue Exception => e
      log :error, "something bad"  
    end
  end
end

[benlangfeld]

That seems as good a "solution" as any besides ditching the insanity that is EM.