Estamos tratando de averiguar si usar return
o throw
en Solidity cuando falla una condición y no asumimos la malicia del usuario. Estos son los pros y los contras que hemos descubierto hasta ahora:
throw
throw
con anticipación, advirtiendo al usuarioreturn
throw
.¿Hay otras consideraciones (o mejores prácticas) que debamos tener en cuenta?
Todas las consideraciones en la pregunta son útiles.
throw
es más seguro ya que asegura que no quedan efectos secundarios, pero otra consideración es el informe de errores. Actualmente no throw
hay forma de obtener más información sobre el error, mientras que los eventos y los códigos de error se pueden usar return
para transmitir una razón más granular sobre el error.
Otra cosa a tener en cuenta al usar web3.js es que cuando throw
se encuentra Solidity, actualmente web3.js tiene un problema con false
los valores .
EDITAR: Dado que throw
consume todo el gas, vigile la instrucción EIP 140 REVERT :
La
REVERT
instrucción proporciona una forma de detener la ejecución y revertir los cambios de estado, sin consumir todo el combustible provisto y con la capacidad de devolver una razón.
También puede considerar por qué no usar throw / return:
¿Por qué no usar tirar?
¿Por qué no usar retorno?
contract.doSomeImportantCall()
puede devolver false
, pero la persona que llama esperaba un lanzamiento, por lo que, a menos que verifiquen el valor de retorno, pueden suceder cosas malas.returns (bool _successful, uint _result)
vsreturns (uint _result)
Realmente no hay consenso sobre la forma correcta de hacer las cosas. De hecho, actualmente hay un debate sobre el lanzamiento frente al retorno transfer
en la especificación ERC20 actualizada, por ejemplo.
pablo yabo
ética
throw
consume todo el gas y agregué la aclaración. De lo contrario, una transferencia de éter se revierte con athrow
orevert
.pablo yabo
ética
throw
el éter enviado: ethereum.stackexchange.com/questions/2428/…pablo yabo
ética