If I have a Smart Contract with a different Contract as parameter the parameter can be undefined which would be bad. Is it good practice to have a require(address(paramContract) != 0x0) statement in the constructor?

I'm tempted to do it because it makes sense but it sounds wrong to have a possible throw in the constructor

  • i would do it, if it is necessary to test the contract's argument. like when you are using some contract factory and arguments are dynamic. otherwise i don't really see where it would be necessary Commented Apr 6, 2018 at 13:03

2 Answers 2


Think of the gas

Throwing an exception with require will save you or anyone trying to deploy the contract from wasting gas if the arguments are incorrect.

It's better that it causes an exception and alerts the creator that there's an issue with the contract's parameters, rather than simply allowing them to waste gas sending a transaction that will create a possibly irredeemably incorrectly configured contract.

If the contract has an error then the creator will get a notification from their client that the transaction won't succeed and then they can double check their parameters to see what they've done wrong.

  • using throw will consume all the gas. It's better to use require then. Commented Apr 6, 2018 at 13:31
  • You can see in the question the OP is actually talking about throwing an exception with require(). For clarification, there's also a deprecated instruction called throw() which results in an invalid JUMP occurring and thus uses up all the gas and causes the call to fail. Usage of this instruction is to be strongly discouraged. I've clarified the answer.
    – supakaity
    Commented Apr 6, 2018 at 13:37
  • Ah yes, np, I was too quick to respond Commented Apr 6, 2018 at 13:48

No. It's not wrong.

The priority should be for the contract to protect the integrity of the application state at all times. An invalid configuration must not be allowed to persist even if it's the result of a developer/operations/deployment error.

Allowing the contract to carry on as if nothing is wrong when actually something is very wrong is incorrect, in my opinion. I'm thinking of a particular incident that resulted in the loss of upwards of USD $100 million. As with most catastrophies, there are multiple factors to consider. One can think of various safety measures, any one of which would have prevented the unfortunate sequence of events.

Constructor arguments are not the only method of ensuring a completely valid configuration before normal processing begins. One can consider a process with multiple calls to multiple contracts to rig up inter-dependencies. That would be okay as well, provided the "normal" functions are guarded with something like onlyIfInitialized.

Nothing at all wrong with a constructor that refuses to proceed unless the configuration is value. This is often the simplest method and easiest to reason about, as it should be. Don't let the possible loss of a little gas, once, cause any concern at all.

Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.