2011-01-28 8 views
11

Al hacer las propias excepciones personalizadas como¿Cuál es un lugar convencional para mantener definiciones de excepciones personalizadas en un proyecto de rieles?

class ThingExploded < StandardError; end 
class ThingIsMissing < StandardError; end 

Dónde es un buen lugar para guardar estos? Estaba considerando lib/exceptions.rb ... y también ponderando si sería más apropiado acercarlos de algún modo al código que los utiliza.

+1

¿Desea la etiqueta "tragado-excepciones" o "excepciones"? –

+0

arreglado, gracias :) –

+7

El diseño de Rails con frecuencia recompensa poner cosas en ciertos directorios y castiga ponerlas en otro lugar. Por lo tanto, se pueden dar consejos objetivos sobre dónde colocar algo en un proyecto de Rails. No estoy de acuerdo con que esta pregunta deba cerrarse. –

Respuesta

1

Voy con app/models/model_name/exceptions.rb, manteniéndolos dentro del módulo.

+1

Siempre y cuando solo los use en un solo modelo. – EasierSaidThanDone

+1

¿Usado para decir aumento? Entonces creo que estoy de acuerdo. –

17

Probablemente vaya con lib/exceptions/thing_exploded.rb para mantener cada clase en un archivo separado.

+0

¿Por qué cada excepción debe mantenerse en un archivo separado? Las clases de excepción son bastante simples, entonces ¿es mejor guardarlas en un solo lugar? – mrzasa

+1

@mrzasa No tienen que ir en un archivo separado si está definiendo excepciones locales para usar en una sola clase. Sin embargo, si desea compartir excepciones en la aplicación, este es el enfoque que recomendé cuando lib se cargó automáticamente. Sin embargo, ahora probablemente solo los incluiría en un archivo y explícitamente lo requeriría de forma similar a como lo hace [ActiveRecord] (https://github.com/rails/rails/blob/master/activerecord/lib/active_record/errors. rb). –

+0

@PeterBrown Puesto que definitivamente son una parte inmanente de la aplicación, deberían aparecer en algún lugar bajo 'app', no' lib'. – skalee

9

A menos que sus excepciones sean tan severas que no deban ser rescatadas, no es apropiado subclasificarlas de Exception.

excepciones como fatal y NoMemoryError son subclases de excepción, así que si tenía un código como rescue Exception para manejar ThingExploded y ThingIsMissing, serías rescatando todo tipo de cosas que es mejor dejar solo.

En su lugar, es mejor hacer una subclase de StandardError.

+0

'rescue Exception' atrapará también a aquellos, he aquí: https://gist.github.com/3c43788eabaa52ae9b98 –

+0

' rescue Exception' captará todo, tal vez estás pensando en 'rescue' desnudo que solo atrapa' RuntimeError's? Alguna discusión interesante aquí: http://stackoverflow.com/questions/4800698/what-is-the-difference-between-raise-foo-and-raise-exception-newfoo –

+0

Hizo algo más de experimentación ... rescatar 'rescue' rescatará 'StandardError' y cualquier subclase de la misma. 'rescue Exception' rescatará cualquier excepción de cualquier tipo. Creo que entiendo mejor tus consejos, y creo que supones que utilizo 'rescue Exception' en mi código. Yo no. Siempre rescato la excepción personalizada muy específica, y dejo que las excepciones más desagradables lleguen a niveles más altos donde rescato todas las 'Excepciones', las informo a los desarrolladores y las oculto a los usuarios. –

Cuestiones relacionadas