¿Alternativa a rescatar en Ruby?

Parece que he begin ... rescue ... end declaraciones begin ... rescue ... end en todo mi código! Esto no parece ser lo correcto a hacer.

¿Alguien puede sugerir cómo puedo detectar cualquier excepción sin tener que colocar todo dentro de begin ... rescue ... end ? ¿Alguna forma de simplemente decirle a Ruby que se calle y siga adelante incluso si se produce una excepción?

Como en otros idiomas, para cualquier progtwig no trivial, realmente necesita una architecture bien pensada para procesar las excepciones. Un enfoque es definir los ámbitos de manejo de excepciones dentro de su proyecto, y luego, típicamente, desea capturar (rescatar) excepciones en los límites del scope. Hay una compensación. Cuanto más cerca esté de la stack en la que se produjo la excepción, mayor será la información contextual que tenga sobre la condición que la provocó. Si intenta ser demasiado granular, se encuentra con los problemas que ha descrito. Por otro lado, si solo detecta excepciones en la parte superior de la stack (en “main”), entonces no hay contexto. Por lo tanto, definir los ámbitos de manejo de excepciones implica evaluar esa compensación en relación con su progtwig o sistema en particular.

Ruby nos da la posibilidad de “volver a intentarlo”, no disponible en otros idiomas. Esto debe ser usado con moderación! Pero donde tiene sentido (por ejemplo, esperar a que se libere la red o un recurso), dichas excepciones deben manejarse de manera muy local.

De lo contrario, tiendo a definir los ámbitos de excepción en un nivel bastante general en un proyecto grande. A menudo es útil capturar algo de información contextual, ya que la excepción brota desde el punto de origen hasta los distintos límites de scope de la excepción. Para ayudarlo con esto, puede extender la jerarquía de clases de excepción de Ruby definiendo algunos de sus propios tipos de excepción específicos de la aplicación, pero nuevamente, hay compensaciones. Su proyecto debe tener estándares claros sobre cuándo usar tipos de excepción personalizados frente a la captura de datos contextuales en el campo del mensaje, qué tipo de información debe contener el campo del mensaje, etc., y una estrategia para catalogar los mensajes que su código puede generar.

En la mayoría de los casos, se puede permitir que las excepciones se propaguen hacia un controlador centralizado, que se registren (para el equipo técnico y el soporte), para generar mensajes de error útiles para el usuario y para determinar si la condición es lo suficientemente grave como para requerir su progtwig. salir. En general, todas las excepciones deben manejarse dentro de su código o en el marco de la aplicación que está utilizando. No se debe permitir que ninguna excepción se escape al manejo de excepciones predeterminado del tiempo de ejecución del idioma o del sistema operativo.

Esos son mis pensamientos basados ​​principalmente en la experiencia con otros idiomas, pero creo que se aplican de manera bastante general. En pocas palabras, en un proyecto grande debe esforzarse mucho en diseñar un manejo excepcional, en lugar de un enfoque ad hoc.

 def action yield rescue .... ensure .... end action { stuff_goes_here } 

Una cosa que puede hacer que se vea un poco más limpio es poner el rescate al final del método para que no necesites un comienzo y otro nivel de sangría:

 def get_file_prompt print "Enter file name: " return File.open(read) rescue StandardError puts "File could not be opened" return nil end 

Bueno no. Todo el punto de las excepciones es que son condiciones que deben manejarse.

Piénsalo de esta manera: ¡ Las excepciones son tus amigos! Sin ellos, tendrías que escribir muchas declaraciones de condiciones aburridas que serían difíciles de leer y mantener.

Si está aprendiendo Ruby (o cualquier otro idioma con un sistema de excepción), tratar con excepciones es uno de los aspectos más importantes, y le convendría dedicar tiempo a descubrir cómo manejarlas, cuándo volver a boostlas. y cuando es seguro ignorarlos.