handle the "no limiter" case more obviously

This is no semantic change since gen_server:cast(undefined, ...)
returns 'ok'. However, it only does so because it catches the 'badarg'
error thrown by erlang:send. It is probably more efficient to not
attempt the send in the first place. Plus for documentation purposes,
and to keep dialyzer happy, it is useful to state explicitly which
functions are expected to be called on an 'undefined' limiter.

1 files changed, 8 insertions, 10 deletions

diff --git a/src/rabbit_limiter.erl b/src/rabbit_limiter.erl
index 824de0724f..e02f77b1b2 100644
--- a/src/rabbit_limiter.erl
+++ b/src/rabbit_limiter.erl
@@ -70,21 +70,19 @@ limit(LimiterPid, PrefetchCount) ->
 
 %% Ask the limiter whether the queue can deliver a message without
 %% breaching a limit
-can_send(undefined, _QPid) ->
-    true;
-can_send(LimiterPid, QPid) ->
-    gen_server:call(LimiterPid, {can_send, QPid}).
+can_send(undefined, _QPid) -> true;
+can_send(LimiterPid, QPid) -> gen_server:call(LimiterPid, {can_send, QPid}).
 
 %% Let the limiter know that the channel has received some acks from a
 %% consumer
-ack(LimiterPid, Count) ->
-    gen_server:cast(LimiterPid, {ack, Count}).
+ack(undefined, _Count) -> ok;
+ack(LimiterPid, Count) -> gen_server:cast(LimiterPid, {ack, Count}).
 
-register(LimiterPid, QPid) ->
-    gen_server:cast(LimiterPid, {register, QPid}).
+register(undefined, _QPid) -> ok;
+register(LimiterPid, QPid) -> gen_server:cast(LimiterPid, {register, QPid}).
 
-unregister(LimiterPid, QPid) ->
-    gen_server:cast(LimiterPid, {unregister, QPid}).
+unregister(undefined, _QPid) -> ok;
+unregister(LimiterPid, QPid) -> gen_server:cast(LimiterPid, {unregister, QPid}).
 
 %%----------------------------------------------------------------------------
 %% gen_server callbacks