Basically, you should handle any error as soon as it is possible - so if you re calling webservice wrap all the calls in a try/catch block and handle the error there - you can, for example, log the exact error, aggregate many webservice-related exception in more generic, DataSourceFaultException (name is only for example), which will be then received by UI and UI will be able to easily determine, that it can t display requested info because communication failed, and choose to retry, notify user or do anything else.
However - with long running application there are many more errors you ll have to deal with. Many of them are not easy to predict, as they re not necessarily related to any specific call - you can run out of memory, a recursion might cause stack overflow, a system timer can reach it s max value and start from the beginning etc.
You shouldn t handle those errors in every method, as it will only hurt code readibility and will be error prone. Those errors are best handled by UnhandledException event. However, you must remember, that when the exception reaches UnhandledException event, you cannot assume anything about state of your application - the error might have corrupted some (or even all) of internal state. So when such condition occurs, it s best to try to create an error log and gracefuly restart the application (not necessarily whole application - maybe it will be possible to reinitialize application s state - if so, that s a valid option too. However, you must be aware that you won t be able to recover from some errors and handle such situation anyway).