README.md in resque-retry-1.7.3 vs README.md in resque-retry-1.7.4

@@ -229,12 +229,12 @@
 ```ruby
 class ExampleJob
   extend Resque::Plugins::Retry
   @queue = :testing
 
-  def self.retry_delay(exception)
-    if exception == SocketError
+  def self.retry_delay(exception_class)
+    if exception_class == SocketError
       10
     else
       1
     end
   end
@@ -357,11 +357,16 @@
 
 You may also want to specify different retry delays for different exception
 types. You may optionally set `@retry_exceptions` to a hash where the keys are
 your specific exception classes to retry on, and the values are your retry
 delays in seconds or an array of retry delays to be used similar to exponential
-backoff.
+backoff.  `resque-retry` will attempt to determine your retry strategy's
+`@retry_limit` based on your specified `@retry_exceptions`.  If, however, you
+define `@retry_limit` explicitly, you should define `@retry_limit` such that it
+allows for your retry strategies to complete.  If your `@retry_limit` is less
+than the number of desired retry attempts defined in `@retry_exceptions`, your
+job will only retry `@retry_limit` times.
 ```ruby
 class DeliverSMS
   extend Resque::Plugins::Retry
   @queue = :mt_messages
 
@@ -372,13 +377,19 @@
   end
 end
 ```
 
 In the above example, Resque would retry any `DeliverSMS` jobs which throw a
-`NetworkError` or `SystemCallError`. If the job throws a `NetworkError` it
-will be retried 30 seconds later, if it throws `SystemCallError` it will first
-retry 120 seconds later then subsequent retry attempts 240 seconds later.
+`NetworkError` or `SystemCallError`. The `@retry_limit` would be inferred to be
+2 based on the longest retry strategy defined in `@retry_exceptions`. If the job
+throws a `NetworkError` it will be retried 30 seconds later with a subsequent
+retry 30 seconds after that. If it throws a `SystemCallError` it will first
+retry 120 seconds later then a subsequent retry attempt 240 seconds later.  If
+the job fails due to a `NetworkError`, Resque would retry the job in 30 seconds.
+If the job fails a second time, this time due to a `SystemCallError`, the next
+retry would occur 240 seconds later as specified in the `SystemCallError`
+array defined in `@retry_exceptions`.
 
 ### <a name="fail_fast"></a> Fail Fast For Specific Exceptions
 
 The default will allow a retry for any type of exception. You may change
 it so specific exceptions fail immediately by using `fatal_exceptions`:
@@ -509,11 +520,11 @@
   @queue = :testing
   @retry_delay = 1
 
   def self.work(*args)
     user_id, user_mode, record_id = *args
-    
+
     Resque.enqueue_to(
       target_queue_for_args(user_id, user_mode, record_id),
       self,
       *args
      )
@@ -529,11 +540,11 @@
 
   def self.target_queue_for_args(*args)
     user_id, user_mode, record_id = *args
 
     if user_mode
-      'high
+      'high'
     else
       'low'
     end
   end
 end
@@ -583,10 +594,10 @@
 end
 ```
 
 This saves you from having to run a "house cleaning" or "errand" job.
 
-The expiary timeout is "pushed forward" or "touched" after each failure to
+The expiry timeout is "pushed forward" or "touched" after each failure to
 ensure it's not expired too soon.
 
 ### <a name="callbacks"></a> Try Again and Give Up Callbacks
 Resque's `on_failure` callbacks are always called, regardless of whether the
 job is going to be retried or not. If you want to run a callback only when the