Test Automation Recovery Scenarios: how much recovery

This article is not specific to QTP but elaborates a more general problem with functional test automation. I caught the fancy of recovery scenarios when came across such feature in QTP. QTP's motive is to recover from problems of unexpected pop up windows (though concept itself is contradictory and requires you to know object properties of unknown window in advance!) .Though soon realized that it is more of marketing gimmick than of being of much importance to automation it self. Some thing which always puzzled me was how much of such scenarios to use.
While under going In house QTP training we were told to even check presence of objects before exercising them. This is to make sure that QTP does not throw any pop up error during test case execution. (at least this is what we were told during training). Later I realized that using QTP properties could be to order QTP do what is intended (though in a limited manner).
This idea of checking every object before test freaked me out. I started wondering if I have to check each object first before I perform any operation. Being a Selenium enthusiast I started doing some thing like -

public safeType (String obj, String testData) {
    if(selenium.IsElementPresent(obj))
       selenium.type(obj, test Data);
    else
       Reporter.log("Element: " +obj+ ", NOT found")
}

But then came across Unchecked Exception in java, and realized that non availability of object on page should be treated as run time exception and test automation should not make efforts to come out of these exceptions. But then I thought that "safe" approach could be used for non mandatory fields/tests on a page which would post error on test report but will let tests continue the execution. (Remember unavailability of an element makes entire tests stop in selenium). Well I am not sure how practical this approach is but I am curious to know how you would have approached it.