¿Cómo consigo que ruby imprima una traza inversa completa en lugar de una truncada?

También podría hacer esto si desea un simple de una sola línea:

puts caller

Esto produce la descripción del error y una buena traza limpia y con sangría:

begin               
 # Some exception throwing code
rescue => e
  puts "Error during processing: #{$!}"
  puts "Backtrace:\n\t#{e.backtrace.join("\n\t")}"
end

IRB tiene una configuración para esta horrible "característica", que puede personalizar.

Crea un archivo llamado ~/.irbrc que incluya la siguiente línea:

IRB.conf[:BACK_TRACE_LIMIT] = 100

Esto le permitirá ver 100 marcos de pila en irb, al menos. No he podido encontrar una configuración equivalente para el tiempo de ejecución no interactivo.

Se puede encontrar información detallada sobre la personalización de IRB en el libro de Pickaxe .

Un forro para callstack:

begin; Whatever.you.want; rescue => e; puts e.message; puts; puts e.backtrace; end

Un forro para callstack sin todas las gemas:

begin; Whatever.you.want; rescue => e; puts e.message; puts; puts e.backtrace.grep_v(/\/gems\//); end

Un liner para callstack sin todas las gemas y relativo al directorio actual

begin; Whatever.you.want; rescue => e; puts e.message; puts; puts e.backtrace.grep_v(/\/gems\//).map { |l| l.gsub(`pwd`.strip + '/', '') }; end

Esto imita el rastro oficial de Ruby, si eso es importante para usted.

begin
  0/0  # or some other nonsense
rescue => e
  puts e.backtrace.join("\n\t")
       .sub("\n\t", ": #{e}#{e.class ? " (#{e.class})" : ''}\n\t")
end

Curiosamente, no maneja 'excepción no controlada' correctamente, reportándolo como 'RuntimeError', pero la ubicación es correcta.

Estaba recibiendo estos errores al intentar cargar mi entorno de prueba (a través de rake test o autotest) y las sugerencias IRB no ayudaron. Terminé envolviendo todo mi test / test_helper.rb en un bloque de inicio/rescate y eso arregló las cosas.

begin
  class ActiveSupport::TestCase
    #awesome stuff
  end
rescue => e
  puts e.backtrace
end

[examinar todos los hilos de vuelta para encontrar al culpable]
¡Incluso la pila de llamadas completamente expandida puede ocultar la línea de código ofensiva real de usted cuando usa más de un hilo!

Ejemplo: Un hilo está iterando ruby Hash, otro hilo está tratando de modificarlo. BOOM! Excepción! Y el problema con el seguimiento de pila que obtienes al intentar modificar el hash 'ocupado' es que te muestra una cadena de funciones hasta el lugar donde intentas modificar el hash, pero no lo hace ¡muestra quién lo está iterando en paralelo (quién lo posee)! Esta es la manera de averiguarlo imprimiendo stack trace para TODOS los subprocesos actualmente en ejecución. Así es como se hace esto:

# This solution was found in comment by @thedarkone on https://github.com/rails/rails/issues/24627
rescue Object => boom

    thread_count = 0
    Thread.list.each do |t|
      thread_count += 1
      err_msg += "--- thread #{thread_count} of total #{Thread.list.size} #{t.object_id} backtrace begin \n"
      # Lets see if we are able to pin down the culprit
      # by collecting backtrace for all existing threads:
      err_msg += t.backtrace.join("\n")
      err_msg += "\n---thread #{thread_count} of total #{Thread.list.size} #{t.object_id} backtrace end \n"
    end

    # and just print it somewhere you like:
    $stderr.puts(err_msg)

    raise # always reraise
end

El fragmento de código anterior es útil incluso con fines educativos, ya que puede mostrarle (como x-ray) cuántos hilos tiene en realidad (frente a cuántos pensó que tenía, muy a menudo esos dos son números diferentes;)