Solidity – Fixing Remix Error: Function Declared as View but Potentially Modifies State

eventsremixsolidityview

This code is inside a view function and gives the error : Function declared as view but this potentially modifies state.

if ( auction.iS == false){      //check if such auction exists
emit NoSuchAuction(msg.sender, _auctionName); 
return; }

NoSuchAuction() is an event.
_auctionName is a string.
auction is a structure and iS is a boolean.

Best Answer

Events take a place in the blockchain which can be filtered. But functionality of a view function cannot make any changes in the blockchain state. That's why you are getting the error. Use return, to get the parameters back, if event is required, remove the view from it. View & event cannot live together.

Know more about state change : http://solidity.readthedocs.io/en/latest/contracts.html?highlight=emit#view-functions

Related Solutions

Solidity View Function Error – Expression Modifies State Requires Payable

Let's go over the compilation error that you're getting:

Function declared as view

That one is clearly true, since this is how you've declared the function:

function getHighestBidID() public onlyOwner view ...

But this expression modifies the state

That one is also true, since you are indeed modifying one of the state-variables:

winneraddress = _highestidaddress;

A view function can read state-variables, but it cannot write (modify) them.

So either get rid of the view, or get rid of the winneraddress = _highestidaddress.

Solidity – Solving ‘Function Cannot Be Declared as View Due to Potential State Modification’

There are a few different perspectives into this. Let's see.

Blockchain's perspective

The blockchain basically just stores data. Data can be read from any node. State changes aren't free, reading data from a node is free. The blockchain doesn't know if someone reads data locally from a node - it only cares if someone issues a transaction to change the blockchain state, and that costs.

Tooling

Tooling around the blockchain provide different ways of calling contracts' functionality. Modifying the blockchain state always requires a real transaction. But it's also fine to issue a static call to non-view functions - in that case the wannabe-transaction is issued only to your local node (or whichever node provider you use) and the state changes it performs are not persisted - but its operations are free.

One issue with tooling is that it typically relies on various 'hints' about how to call different functionality. For example if you want to call a non-view function, tooling typically offers you to issue a real transaction.

Most tooling (for example ethers.js) offer ways to call whichever function with whichever type - a local/static call or with a real transaction. It just may not be the most straightforward way, since the tooling tries to make things easy for you (by assuming you always want a real transaction to a non-view function).

Wallets

These are often quite dumbed-down versions of tooling, but a lot more user friendly. It may be difficult, if not impossible, to configure your wallet to issue a read-only call to a non-view function, for example. This of course applies only to functionality which is not triggered by various tooling (for example by a website running ethers.js).

Conclusion

In theory it's fully up to the caller whether to issue a real transaction or a local read-only call. In reality it depends on the used tools, whether they support that and only provide what they think you want.

Best Answer

Related Solutions

Solidity View Function Error – Expression Modifies State Requires Payable

Solidity – Solving ‘Function Cannot Be Declared as View Due to Potential State Modification’

Related Topic