no problem man, if you want the script to run 24/7 without error. use this to call the Humanoid.
local hum = char:WaitForChild("Humanoid", 0.1) --The 0.1 adds a timer for WaitForChild, so it's not just a while true do loop.
Usually when I see code like this and have an error where the Humanoid or character is having issues, it’s because of how Destroy() works. Destroy() does not set an instance to nil–instead, it actually sets the parent to nil. This means that if you have a variable pointing to the instance you call Destroy() on, it will still have access to this instance. How this is related to Characters and Humanoids is through the fact that when players die, internally the game calls Destroy() on their Character. This means that if in some script of your own you had something like local Character = Player.Character then after the player dies Character still points to something.
When I see your first line of code, local hum = char:WaitForChild("Humanoid"), I immediately notice that there is nothing such that everytime a new character is created (every time the player is spawned) the hum variable is not set to the new character’s Humanoid. This means that after dying and attempting to load an animation on the old humanoid the game errors because the humanoid doesn’t actually exist. This leads to the misleading situation that you state:
If you attempt to print the old Humanoid, you will get a result, leading you to believe that the Humanoid exists–which it does. Except, it’s the wrong Humanoid.
One solution to this is to set char to the new character every time the Player.CharacterAdded event is fired and to then set hum to the new Humanoid of the new Character. However, the cleaner solution is what @Laqotaa suggested, which is to simply put the script in StarterCharacterScripts. This is because whenever the player’s character is spawned, a new copy of the script is also loaded into the new character, which guarantees that every local hum = char:WaitForChild("Humanoid") points to the correct Humanoid.