receive function allows a contract to accept eth via a send() or transfer(). As someone thought it was a good idea to have both a
receive and a fallback function, I was curious what sort of scenario would be helped by having an additional fallback function? I can't think of one so I figure I am missing something.
receive function is called if no other function is found and the transaction includes Ethers. The
fallback function is called if no other function is found.
Assuming the transaction doesn't call any known function, the
fallback function is useful to catch non-Ether transactions.
Here are a few example use cases:
Someone trying to call a
transferfunction (thinking it's an ERC20 contract) on a non-token contract - you could for example revert the transaction stating "You called the wrong contract, this isn't ERC20 contract".
A contract which simply needs to store addresses of those who are trying to interact with it for some reason, so the user can just send an empty transaction to the contract.
In general catching people who try to call functions which don't exist (probably using the wrong contract).
Granted, I can't think of many reasonable use cases for this either.
You can read more about the details for example here: https://solidity.ethereum.org/2020/03/26/fallback-receive-split/