ETHEREUM SMART CONTRACTS DEVELOPMENT

Solidity Fundamentals: Functions

Functions: Part Two

Ferdi Kurt

Published in

Coinmonks

4 min readJan 29, 2021

Hello folks! This part will be the final part of Solidity Fundamentals. We will continue to work on functions and examine the following subjects;

receive Ether Function
fallback Function
Function Overloading
Events

receive Ether Function

receive function declared using receive() external payable { … } without function keyword that can’t have arguments, can’t return anything, and must have external visibility and payable state keyword. One contract can have at most one receive function. It triggers on plain Ether transfers via the usage of send() or transfer(). If contract doesn’t have this function but has payable fallback function, this fallback function will be called on a plain Ether transfer. When neither receive nor payable fallback function exists, contract can’t receive Ether through regular transactions and throws an exception.

Warning: Contracts that receive Ether directly (without a function call, i.e. using send or transfer) but do not define a receive Ether function or a payable fallback function throw an exception, sending back the Ether (this was different before Solidity v0.4.0). So if you want your contract to receive Ether, you have to implement a receive Ether function (using payable fallback functions for receiving Ether is not recommended, since it would not fail on interface confusions).

fallback function

A contract can have at most one fallback function, declared using fallback () external [payable] without function keyword. It can’t have arguments, can’t return anything, and must have external visibility. It executes when the following situation occurs;

a function that does not exist in contract,
Plain Ether sent to the contract without any msg.data provided and there is no receive() ether function. In this scenario, fallback function also must be marked aspayable.

Warning: A payable fallback function is also executed for plain Ether transfers, if no receive Ether function is present. It is recommended to always define a receive Ether function as well, if you define a payable fallback function to distinguish Ether transfers from interface confusions.

Function Overloading

Overloading is a process when a contract have multiple functions of the same name but with different parameter types.

Warning: Overloaded functions are also present in the external interface. It is an error if two externally visible functions differ by their Solidity types but not by their external types.

Events

Events in Solidity are the same as events in other programming languages and generally used to inform the calling application about the current state of the contract with the help of the logging functionality of EVM. When you call them, they cause the arguments to be stored in transaction’s log — a special data structure in the blockchain. Logs have two portions for keeping parameters: data and topics.

There are two types of Solidity event parameters: indexed and not indexed. We can mark up to three parameters as indexed which adds them to a special data structure known as topics that allow us to search for events, for example filtering a sequence of blocks for certain events or even filter events by the contract address that emitted it. All parameters without the indexed are data part of the log.

Note: The hash of the signature of the event is one of the topics, except if you declared the event with the anonymous specifier. This means that it is not possible to filter for specific anonymous events by name, you can only filter by the contract address. The advantage of anonymous events is that they are cheaper to deploy and call.

We can use events and listen to them for updating our off-chain applications’ states and also as a cheaper form of storage (more on later in Advanced Solidity).

See below events for more details after related functions’ executions.

EscrowPlanCreated event emitted with execution of function addEscrowPlan.