Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Rails is in no way consistent in its use of exceptions. <code>find</code> will raise an exception if no object is found, but for saving you can choose what behaviour you want. The most common form is this:</p> <pre><code>if something.save # formulate a reply else # formulate an error reply, or redirect back to a form, or whatever end </code></pre> <p>i.e. <code>save</code> returns true or false. But there is also <code>save!</code> which raises an exception (adding an exclamation mark to the end of a method name is a Rubyism for showing that a method is "dangerous", or destructive, or simply that it has side-effects, the exact meaning depends on the context). </p> <p>There is a valid reason for why <code>find</code> raises an exception, though: if a <code>RecordNotFound</code> exception bubbles up to the top level it will trigger the rendering of a 404 page. Since you usually don't catch these exceptions manually (it's rare that you see a <code>rescue ActiveRecord::RecordNotFound</code> in a Rails app), you get this feature for free. In some cases though, you want to do something when an object does not exist, and in those cases you have to catch the exception.</p> <p>I don't think that the term "best practice" actually means anything, but it is my experience that exceptions aren't used for control of flow in Ruby anymore than in Java or any other language I have used. Given that Ruby doesn't have checked exceptions, you deal with exceptions much less in general.</p> <p>In the end it's down to interpretation. Since the most common use case for <code>find</code> is retrieving an object to display it, and that the URL for that object will have been generated by the application, it may very well be an exceptional circumstance that the object cannot be found. It means that either the application is generating links to objects that don't exist, or that the user has manually edited the URL. It can also be the case that the object has been removed, but a link to it still exist in a cache, or via a search engine, I would say that that too is an exceptional circumstance.</p> <p>That argument applies to <code>find</code> when used as in your example, i.e. with an ID. There are other forms of <code>find</code> (including the many <code>find_by_*</code> variants) that actually search, and those don't raise exceptions (and then there is <code>where</code> in Rails 3, which replaces many of the uses of <code>find</code> in Rails 2). </p> <p>I don't mean to say that using exceptions as control of flow is a good thing to do, just that it's not necessarily wrong that <code>find</code> raises exceptions, and that your particular use case is not the common case.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload