Disadvantages of using `call` function

Question

Hey guys, I was reading about low-level methods of calling other contract functions and I found the following description of call method:

This is the recommended method to use when you're just sending Ether via calling the fallback function. However it is not the recommend way to call existing functions.

Few reasons why low-level call is not recommended:

• Reverts are not bubbled up
• Type checks are bypassed
• Function existence checks are omitted

Honestly, I don't really understand the points that authors are talking about. Please, can you explain/detalize those arguments why low-level call for existing functions is not recommended?

Answer 1

a) Reverts are not bubbled up. It means that when you use a low-level call like call() or delegateCall() and it reverts, you don't receive information about why it reverted. You call it like:

(bool success, bytes memory result) = targetContract.call(data);

and in the case it reverts in the targetContract your cal returns success = false, but without reverted reason. not 'bubbled up' it means that the error are not passed back. In order to get the errors you would have to use some assembly like this:

if (!success) { 
  if (result.length == 0) revert();
  assembly {
    revert(add(32, result), mload(result))
  }

to get the revert reason

b) Type checks are bypassed: When using .call(data) the param data has encoded the args, and at this point, you can not check the types of the args (unit, address) etc.. To overcome this issue you can always trust the data encoded by

data = abi.encodeWithSignature(
                "method(type1,type2)",
                arg1,
                arg2
            ) 

c) Function existence checks are omitted: when using a low-level call, it won't check whether the function exists or not, it will do the call anyway. Something I find useful is, if the interface is available, to check if the method exists.

Hope it helps!