What is the purpose of this gen_server.erl code?

Question

unregister_name({local,Name}) -> _ = (catch unregister(Name)); unregister_name({global,Name}) -> _ = global:unregister_name(Name); unregister_name({via, Mod, Name}) -> _ = Mod:unregister_name(Name); unregister_name(Pid) when is_pid(Pid) -> Pid. 

This is from gen_server.erl . If _ always matches and the match is always evaluated using the right-side expression, what are the _ = expression() lines that do here?

Answer 1

Normally _ = ... are used to disable dialyzer warnings about return values ​​of a mismatch function when its -Wunmatched_returns parameter is -Wunmatched_returns . As explained in the documentation:

 -Wunmatched_returns Include warnings for function calls which ignore a structured return value or do not match against one of many possible return value(s). 

By explicitly matching the return value with the _ "do not care" variable, you can use this useful dialyzer option without seeing warnings about return values ​​that you do not need.

Answer 2

In Erlang, the last expression of a function is the return value, so it might be tempting for someone to check that global:unregister_name/1 or Mod:unregister_name(Name) return and try to match the template with this.

_ = expression() does nothing special, but hints that this return value should be ignored (for example, because they are not documented and can be changed). However, in the last expression, Pid is returned explicitly. This means that you can map the pattern as follows:

 case unregister_name(Something) of Pid when is_pid(Pid) -> foo(); _ -> bar() end. 

To summarize: these lines do nothing, but when someone reads the source code, they show the intention of the original programmer.

Unfortunately, this particular function is not exported, and in the source module it is never used in accordance with the template, so I have no example for backup :)

Answer 3

And I will note that since stumbled upon this :

The power of ten rules for developing critical security code

Gerard J. Holtzmann

NASA / JPL Lab for Reliable Software Pasadena, CA

91109

[...]

7. Rule: the return value of non-void-functions must be checked by each calling function, and the validity of the parameters must be checked inside each function.

   Rationale: Perhaps this is the most frequently violated rule and, therefore, somewhat more suspicious, as a rule. In its strictest form, this rule means that even printf and file closure statements must be checked. You can make the case, however, that if the answer to the error is rightfully no different from the answer to success, by explicitly checking the return value. This often happens with print and close calls. In such cases, it may be acceptable to explicitly pass the value of the returned function to (void) - thereby making the programmer explicitly and not by chance decide to ignore the returned value. In more doubtful cases, the comment should be to explain why the return value does not matter. In most cases, although the return value of the function should not be ignored, especially if error return values ​​should be propagated up the function chain of calls. Standard libraries violate this rule perfectly with potentially serious consequences. See, for example, what happens if you accidentally execute strlen (0) or strcat (s1, s2, -1) using the standard C string library - it's ugly. Keeping the general rules, we guarantee that exceptions must be justified, with mechanical checkers violating violations. Often, it will be easier to follow the rule than to explain why inadmissibility may be acceptable.