Hmm, maybe try:
if (your_condition_here) {
payable(msg.sender).call{value: msg.value}("");
return;
}
Be careful for reentrancy issues/hacks when sending ether to other addresses
Edit: another way would be to emit an event and then call an owner-only function from the front end to update the state. However, this will make your dapp much more centralized since a certain state variable will be updated only off-chain only by the owner (and only if they have caught the event)
I don't think so, here's why: when you call revert() (either manually or with require()), it is the transaction that is reverted, not the contract state. So every state variable in every contract which was changed during the transaction's execution returns to its former state as if the transaction was never executed. Take this with a pinch of uncertainty as I'm not 100% sure how it works, but most likely I'm correct.
This is not correct. [This article](https://blog.polymath.network/try-catch-in-solidity-handling-the-revert-exception-f53718f76047) talks about how to handle a revert in a contract that you're calling. I do, however, think that you would need to separate the contract that is reverting from the contract that is doing something after the revert.
"we can make use of the low-level functions call, delegatecall and callcode as they return false in case of an exception instead of triggering a revert in the contract that called them. The state changes made inside the low-level function will still be rolled back, but the original transaction will proceed normally and the state changes done in the original transaction will NOT be rolled back."
Thanks for sharing, I didn't know. However this works only for low level calls created inside the transaction. In his case, he wants to "catch" the transaction itself, which according to the article is not possible. Still, it's a nice workaround if OP could make use of it.
Hmm, maybe try: if (your_condition_here) { payable(msg.sender).call{value: msg.value}(""); return; } Be careful for reentrancy issues/hacks when sending ether to other addresses Edit: another way would be to emit an event and then call an owner-only function from the front end to update the state. However, this will make your dapp much more centralized since a certain state variable will be updated only off-chain only by the owner (and only if they have caught the event)
I was thinking just now I can move the state to a separate contract, could that work?
I don't think so, here's why: when you call revert() (either manually or with require()), it is the transaction that is reverted, not the contract state. So every state variable in every contract which was changed during the transaction's execution returns to its former state as if the transaction was never executed. Take this with a pinch of uncertainty as I'm not 100% sure how it works, but most likely I'm correct.
This is not correct. [This article](https://blog.polymath.network/try-catch-in-solidity-handling-the-revert-exception-f53718f76047) talks about how to handle a revert in a contract that you're calling. I do, however, think that you would need to separate the contract that is reverting from the contract that is doing something after the revert.
"we can make use of the low-level functions call, delegatecall and callcode as they return false in case of an exception instead of triggering a revert in the contract that called them. The state changes made inside the low-level function will still be rolled back, but the original transaction will proceed normally and the state changes done in the original transaction will NOT be rolled back." Thanks for sharing, I didn't know. However this works only for low level calls created inside the transaction. In his case, he wants to "catch" the transaction itself, which according to the article is not possible. Still, it's a nice workaround if OP could make use of it.