If you do encounter a division by 0 during calculations, then odesys will end up returning a value that includes either infinite or nan (or both). That will typically not be noticed immediately, but instead the next call to odesys will very likely end up returning mostly or all nan. Everything will fall apart from there.
There are narrow circumstances under which ode45() will notice the big value and recover smoothly, just saying "Oh, I guess that step failed" -- but for that to happen, you have to get lucky enough that the division by 0 was on the very last of the 6 odefun calls per iteration that ode45 makes. Much more typical is that you just start going haywire and figuring out why can be a pain.
So... What you should can is a test such as
RPF(~isfinite(RPF)) = 1e100; %some big value that is going to be far from normal values
This will eliminate some of the problems, allowing for a cleaner recover.
You should also, however, add an event function through the options structure, and the event function should be marked as Terminal, and Both Directions, and the value to test should be x(2) . An event function such as that will go as close to the border where x(2) becomes 0 as it can, and then will exit ode45 early. You can tell that the exit was early by checking the last time returned.
This particular exception is probably not "removable": if x(jN) becomes 0 because it must due to the initial conditions, then there is not much you can do except quit. There are a lot of other cases where when the exception is detected, that you want to change the boundary conditions. I recommend Mathwork's example ballode which shows how to use events to cause a ball to "bounce" when it hits the floor (it reverses the velocity and then restarts ode45() )
