 This video was brought to you by my patrons. Thank you so much for your support With aggressive code, I would make something like this. Let me show you Assert what this means is that if this is not true, it will stop the the running of the game It will immediately stop the running of the game and say hey this track doesn't exist So you have to fix that. This is what we call aggressive coding or aggressive approach With defensive approach, any error should be Shouldn't be of the concern of the final release. So if the track doesn't exist, whatever The extreme case where the track doesn't exist This node just will simply won't play it because it doesn't exist. So it won't even try to play it So you prevent it from Emitting an error saying hey this track doesn't exist. So this game cannot run With this approach with a defensive approach Basically, you're saying hey The game should never stop running even if there are glitches even if there are bugs the game will keep running And if the player noticed something if the player noticed that hey this track is not playing Uh, they can report a bug so we can fix that. Um, ideally a defensive approach should be Um, you should use a defensive approach on releases, but on development branches and on development Stages of production Uh, it's often better to acknowledge if your code is lacking or if your game is lacking any logic or if the logic is Is not good enough So it's very Usual to go to an aggressive approach. So you prevent any bugs in your game But I like to leave on the edge of the cliff. So I always So I always ignore that my games can bug out If they if there's a use case reported that my game is not running I try to fix it, but on production. I don't try to fix Uh, minor bugs just stuff that prevents the logic from actually running