Depends on what kind of results you care about. If it's OK to return infinity or NaN (or w/e the result turns into) then by all means divide away. In most cases as long as a valid float is returned then it's fine. Though there are times when edge cases need to be explicitly handled. For example say we are running a cloth simulation, and we do something like this (probably buggy just pay attention to the idea and the division):
for all e in edges
d = e.b - e.a
l = length( d )
correction = (l - EDGE_LENGTH_CONSTANT) * (d / l)
e.b += correction
e.a -= correction.
Everything is fine and dandy right? Two concerns arise:
- Division with the denominator much smaller than numerator -- in this case it's probably fine. Some numerically sensitive applications actually care if a division explodes into a large result and will actively mitigate divisions where the denominator is much smaller than the numerator (for example in gaussian elimination).
- If an edge's endpoints a and b happen to reside a the exact same location INF will probably spread around the cloth making it explode/disappear. Some logic is needed just in case, and the branch predictor will probably more or less ignore the if statement.
The first bullet point will require some thought put into how to construct an appropriate epsilon check (what the epsilon value and scale should be, what kind of comparison to make). The second one is pretty common. But a lot of the time it's OK to just do the divide naively so long it is alright for the application's standards.
