Solidity try/catch is narrower than a lot of people think

Post original

I wrote up a short breakdown of a Solidity footgun I still see people misunderstand: try/catch. The main point: Solidity try/catch is not a general exception handler like in JS/Python/Java. It only catches failures from certain external operations, mainly high-level external calls, contract creation with new, and external library calls. A few gotchas that are easy to miss: - You cannot use it directly with address.call, staticcall, or delegatecall - It does not catch internal function failures - If an external call succeeds but returns malformed data, the caller can still revert during ABI decoding - catch (bytes memory data) is not magic either; decoding that data can also revert if you trust it blindly - try this.someFunction() changes the call into an external self-call, which can affect msg.sender, gas, reentrancy assumptions, and constructor behavior - try/catch is control flow, not a rollback checkpoint for caller-side state changes The malformed return data case is probably the most surprising one. If a contract returns success with empty bytes, but the caller expects a uint256, the external call itself did not fail. The failure happens later when Solidity tries to decode the return value, so the catch block does not save you. For trusted interfaces, high-level try/catch is convenient. For arbitrary or hostile targets, especially when return data matters, a low-level call plus explicit returndata validation is usually a better boundary. Full post with examples: https://blog.researchzero.io/post/solidity-try-catch-what-it-does-and-does-not-catch/   submitted by   /u/researchzero [link]   [comments]