You don't need to.
A math overflow is never considered to be a major fault in Logix5000, neither is it in PLC2, PLC3, PLC5 PLC5/250 etc.
It is only the SLC & MicroLogix families that have it, and strictly speaking, it isn't the math overflow condition that causes the fault, it is the fact that you HAD an overflow status SOMEWHERE in the program scan.
In effect the "overflow trap" bit is pretty useless, it will cause a Major Fault if it is still set when the program scan finishes, but it won't tell you WHERE the ACTUAL overflow set the overflow trap bit.
Every single SLC program I have ever seen has OTU S:5/0 as an unconditional rung at the end of file 2. That explains how useful it is ....
Forget about it in Logix5000, along the same lines as we never had it in 2, 3, 5 etc., and totally ignored it in SLC by resetting it as the last rung in the program.
Going back to your OP, a negative timer preset is declared a Major Fault in Logix5000 as it is scanned, it does not wait until the end of the scan before faulting.
You perhaps need to read up on Fault handling, both at the Program level, and the Controller level. It is possible to read the fault type and code, and clear them if that is appropriate, to allow the controller to carry on without faulting, perhaps just raising alarms for specific faults that can stop erroneous actions.
But in the case of negative timer presets (same goes for ACC values, those are also Major Faults), you have to ask the question "how did it get there?". If you have calculated the preset, you should limit-check the result before moving it into the timer. If it has come from an HMI data-entry, you should limit-check it on the HMI data-entry object.