README.md in rabbit_messaging-0.13.0 vs README.md in rabbit_messaging-0.15.0

@@ -44,10 +44,18 @@
     Personal identifier which used to select exact service.
     As usual, it should be same as default project_id with optional stage_id.
     (I.e. we have project 'support', in production it's project_id is :support,
     but in staging it uses :support1 and :support2 ids for corresponding stages)
 
+
+  * `exception_notifier` (`Proc`)
+    You must provide your own notifier like this to notify about exceptions:
+  
+    ```ruby
+      config.exception_notifier = proc { |e| MyCoolNotifier.notify!(e) }
+    ```
+
   * `hooks` (`Hash`)
 
     :before_fork and :after_fork hooks, used same way as in unicorn / puma / que / etc
 
   * `environment` (one of `:test`, `:development`, `:production`), *default:* `:production`
@@ -83,19 +91,10 @@
         message_id: "uuid",
       }
     }
     ```
 
-  * `exception_notifier` (`Proc`)
-
-    By default, exceptions are reported using `Sentry` (see [sentry gem](https://github.com/getsentry/sentry-ruby)).
-    You can provide your own notifier like this:
-
-    ```ruby
-      config.exception_notifier = proc { |e| MyCoolNotifier.notify!(e) }
-    ```
-
   * `before_receiving_hooks, after_receiving_hooks` (`Array of Procs`)
 
     Before and after hooks with message processing in the middle. Where `before_receiving_hooks` and `after_receiving_hooks` are empty arrays by default.
 
     It's advised to NOT place procs with long execution time inside.
@@ -147,14 +146,18 @@
 
 - Server is supposed to run inside a daemon via the `daemons-rails` gem. Server is run with
 `Rabbit::Daemon.run`. `before_fork` and `after_fork` procs in `Rabbit.config` are used
 to teardown and setup external connections between daemon restarts, for example ORM connections
 
-- After the server runs, received messages are handled by `Rabbit::EventHandler` subclasses.
-  Subclasses are selected by following code:
-  ```ruby
-    "rabbit/handler/#{group_id}/#{event}".camelize.constantize
-  ```
+- After the server runs, received messages are handled by `Rabbit::EventHandler` subclasses in two possible ways:
+  - a)  Subclasses are selected by following code(by default):
+    ```ruby
+    rabbit/handler/#{group_id}/#{event}".camelize.constantize
+    ```
+  - b) you can change default behaviour to your own logic by setting the `handler_resolver_callable` config option with a `Proc` that should return the handler class:
+    ```ruby
+    Rabbit.config.handler_resolver_callable = -> (group_id, event) { "recivers/#{group_id}/#{event}".camelize.constantize }
+    ```
 
   They use powerful `Tainbox` api to handle message data. Project_id also passed to them.
 
   If you wish so, you can override `initialize(message)`, where message is an object
   with simple api (@see lib/rabbit/receiving/message.rb)