_Follow along with this video:_ --- ### Eth Handling Let's pause a moment and focus on this line: ```js require(address(this.balance) == uint256(totalFees), "PuppyRaffle: there are currently players active!"); ``` Effectively, we're checking to assure that we don't withdraw funds that are current in a raffle. Maybe we're just being extra cautious. The idea behind using `address(this).balance` is that - beyond entering the raffle - there's no way this contract can receive funds, so this require should always be ok ... right? ### No Receive, No Fallback, No Problem. Puppy Raffle's hope is that without a receive or fallback function, there should never be a way for this accounting to imbalance. Well, let's test it out. ```js function testCantSendMoneyToRaffle() public { address sendAddy = makeAddr("sender"); vm.deal(sendAddy, 1 ether); vm.expectRevert(); vm.prank(sendAddy); (bool success, ) = payable(address(puppyRaffle)).call{value: 1 ether}(""); require(success); } ``` ::image{src='/security-section-4/33-exploit-mishandling-eth/exploit-mishandling-eth1.png' style='width: 75%; height: auto;'} Running this test, we discover ... it passes! So we're done, right? Everything's secure? Not exactly. ### Wrap Up It may seem like everything is fine here and that the protocol's accounting is secure, but when it comes to the handling of Eth there can be many pitfalls and gotchas you need to look out for. In the next lesson, we'll return to our [**sc-exploits-minimized**](https://github.com/Cyfrin/sc-exploits-minimized) repo to investigate how Puppy Raffle may still be vulnerable in this broad category.