Chapter 7. Functions, Modifiers, and Fallbacks
Solidity is maturing and providing advanced programming constructs so that users can write better smart contracts. This chapter is dedicated to some of the most important smart contract constructs, such as functions, modifiers, and fallbacks. Functions are the most important element of a smart contract after state variables. It is functions that help to create transactions and implement custom logic in Ethereum. There are various types of functions, which will be discussed in depth in this chapter. Modifiers are special functions that help in writing more readily available and modular smart contracts. Fallbacks are a concept unique to contract-based programming languages, and they are executed when a function call does not match any existing declared method in the contract. Finally, every function has visibility attached to it that affects its availability to the external caller, other contracts, and contracts in inheritance.
This chapter covers...
Function input and output
Functions would not be that interesting if they didn't accept parameters and return values. Functions are made generic with the use of parameters and return values. Parameters can help in changing function execution and providing different execution paths. Solidity allows you to accept multiple parameters within the same function; the only condition is that their identifiers should be uniquely named.
The following code snippets show the following multiple functions, each with different constructs for parameters and return values:
- The first function,
singleIncomingParameter, accepts one parameter named _data of type int and returns a single return value that is identified using _output of type int. The function signature provides constructs to define both the incoming parameters and return values. The return keyword in the function signature helps define the return types from the function. In the following code snippet, the return keyword within the function code automatically...
Modifiers are another concept unique to Solidity. Modifiers help in modifying the behavior of a function. Let's try to understand this with the help of an example. The following code does not use modifiers; in this contract, two state variables, two functions, and a constructor are defined. One of the state variables stores the address of the account deploying the contract. Within the constructor, the global variable msg.sender is used to input the account value in the owner state variable. The two functions check whether the caller is the same as the account that deployed the contract; if it is, the function code is executed, otherwise it ignores the rest of the code. While this code works as is, it can be made better both in terms of readability and manageability. This is where modifiers can help. In this example, the checks are made using the if conditional statements. Later, in the next chapter, we will see how to use new Solidity constructs, such as require and assert, to...
The view, constant, and pure functions
Solidity provides special modifiers for functions, such as view, pure, and constant. These are also known as state mutability attributes because they define the scope of changes allowed within the Ethereum global state. The purpose of these modifiers is similar to those discussed previously, but there are some small differences. This section will detail the use of these keywords.
Writing smart contract functions helps primarily with the following three activities:
- Updating state variables
- Reading state variables
- Logic execution
The execution of functions and transactions costs gas and is not free of cost. Every transaction needs a specified amount of gas based on its execution and callers are responsible for supplying that gas for successful execution. This is true for transactions or for any activity that modifies the global state of Ethereum.
There are functions that are only responsible for reading and returning the state variable, and these are like property...
In the chapter relating to data types, we purposely did not explain the functions related to the address data type. Although these functions could have been covered there, some of these functions can execute a fallback function automatically, and hence it is covered here.
Address provides five functions and a single property.
The only property provided by address is the balance property, which provides the balance available in an account (contract or individual) in wei, as shown in the following code snippet:
<<account>>.balance ;
In the preceding code, account is a valid Ethereum address and this returns the balance available in this in terms of wei.
Now, let's take a look at the methods provided by an account.
The send method is used to send Ether to a contract or to an individually owned account. Take a look at the following code depicting the send method:
<<account>>.send(amount);
The send function provides 2,300 gas as a fixed limit...
The fallback functions are a special type of function available only in Ethereum. Solidity helps in writing fallback functions. Imagine a situation where you, as a Solidity developer, are consuming a smart contract by invoking its functions. It is quite possible that you use a function name that does not exist within that contract. In such cases, the fallback function, as the name suggests, would automatically be invoked.
A fallback function is invoked when no function name matches the called function.
A fallback function does not have an identifier or function name. It is defined without a name. Since it cannot be called explicitly, it cannot accept any arguments or return any value. An example of a fallback function is as follows:
A fallback function can also be invoked when a contract receives any Ether. This usually happens using the SendTransaction function available in web3 to send Ether from one account to a contract. However, in this case, the fallback function...
Once again, this was a heavy chapter that focused primarily on functions, including the address functions and the pure, constant, and view functions. The address functions can be intimidating, especially when you consider their multiple variations and their relationship with the fallback functions. If you are implementing a fallback function, remember to pay special attention to testing, especially from a security point of view. You should also pay special attention when using low-level Solidity functions such as send, call, and transfer as they invoke the fallback function implicitly. Always try using contract functions that use ABI as it ensures that the proper function, along with its data types, is being called.
In the next chapter, we will dive deep into the world of events, logging, and exception handling in Solidity. Stay tuned!
