ruby-on-rails - with - try catch ruby

Comience a rescatar el error de no captura

Question

Estoy usando un código de rubí envuelto en un bloque de inicio - rescate, pero de alguna manera logra bloquearse.

El bloque de código se ve así:

# Retrieve messages from server
def get_messages
  @connection.select(''INBOX'')
  @connection.uid_search([''ALL'']).each do |uid|
    msg = @connection.uid_fetch(uid,''RFC822'').first.attr[''RFC822'']
    begin
      process_message(msg)
      add_to_processed_folder(uid) if @processed_folder
    rescue
       handle_bogus_message(msg)
    end
    # Mark message as deleted 
    @connection.uid_store(uid, "+FLAGS", [:Seen, :Deleted])
  end
end

Dado este código, asumiría que si process_message o add_to_processed_folder no pudieran ejecutarse, el rescate se activaría y llamaría handle_bogus_message . Dicho esto, estoy ejecutando este código en un entorno de producción y, a veces, cuando "recibo" un mensaje de correo electrónico (esto se ejecuta desde una tarea de rake) muere con un SyntaxError .

Para ver el mensaje de error, visite http://pastie.org/1028479 y no el mensaje de proceso al que se refiere es el mismo mensaje de proceso anterior. ¿Hay alguna razón por la cual comenzar - el rescate no detectará esta excepción?

Answer 1

rescue sin ningún parámetro acepta excepciones generadas por la clase StandardError. Su tipo de error es SyntaxError, que se hereda de una clase diferente llamada ScriptError. Todas estas clases de error son subclases de la clase Exception. Entonces, como sepp2k sugirió usar la rescue Exception para capturar todo tipo de excepciones.

Answer 2

rescue sin un parámetro simplemente rescata las excepciones que heredan de StandardError . Para rescatar un SyntaxError utilice el rescue SyntaxError .

Para rescatar todas las excepciones, debe usar la rescue Exception , pero tenga en cuenta que es una mala idea (por lo que no es el comportamiento predeterminado de rescue ) como se explica here y here . Especialmente esta parte:

El rescate de la interrupción evita que el usuario use CTRLC para salir del programa.

El rescate de SignalException evita que el programa responda correctamente a las señales. Será infalible excepto por kill -9.