2009-05-06 9 views

Respuesta

181

Porque esa es la forma en que los arquitectos pretenden find (id) para trabajar, como se indica en el RDoc:

Búsqueda por ID - Esto puede ser un ID específico (1), una lista de identificadores (1, 5, 6) o una matriz de identificadores ([5, 6, 10]). Si no se puede encontrar ningún registro para todos los ID enumerados, se generará RecordNotFound.

Si no desea que se levante la excepción, use find_by_id, que devolverá nil si no puede encontrar un objeto con la identificación especificada. Su ejemplo sería User.find_by_id(1).

+0

Pero, ¿cuál es la ventaja de que regrese RecordNotFound? ¿Por qué alguien querría este comportamiento en lugar de simplemente devolver nada? – Arcolye

+2

Se genera RecordNotFound, no se devuelve. Esto permite que el flujo de control de la persona que llama sea diferente, porque no tiene que verificar que el valor de retorno sea nulo (en su lugar, usaría un bloque de inicio/rescate). – runako

+3

Eso todavía no explica por qué es el comportamiento predeterminado donde en la mayoría de las otras partes de ActiveRecord, el comportamiento predeterminado es devolver nil o false para las fallas, y dejar el flujo de control de excepción a los métodos que terminan en un bang (#save!) . –

-3

Además de la explicación de runako, en realidad es muy útil tener la opción de si se genera una excepción o no. Estoy trabajando en una aplicación de blog y quería agregar soporte para ver la entrada de blog siguiente o anterior. Yo era capaz de añadir dos métodos de instancia a mi modelo Post que simplemente regresan nil cuando intenta obtener el post anterior cuando se visualiza el primer mensaje, o el siguiente mensaje cuando se ve el último mensaje:

def next 
    Post.find_by_id(id + 1) 
end 

def previous 
    Post.find_by_id(id - 1) 
end 

Esto evita mi código auxiliar que genera de forma condicional los enlaces Publicar anterior/Siguiente publicación de tener que manejar la excepción RecordNotFound, lo que sería malo porque estaría utilizando una excepción para el flujo de control.

+0

¿No sería esto muy frágil si sus registros en su base de datos no tuvieran identificaciones secuenciales? ? – Pete

+0

@zoltarSpeaks Lo haría, pero en la práctica tienen identificaciones secuenciales, por lo que es un total no problema. –

+25

Si, por ejemplo, tiene una exclusión, obtendrá un error esporádico que es difícil de rastrear. forma de lograr el próximo/previous sería, algo así como: Post.where ("id>?", id) .limit (1) para el siguiente y Publicar.donde ("id

Cuestiones relacionadas