You should not handle the normal program flow via Exceptions. Exceptions should only be handled if you want to do something with it.
If removing an element of an empty list should throw an exception, you should let it throw. If you want to return a new empty list from this method, you should do that.
There is not 1 absolute answer on this matter, you should check it per use-case.
Of course, it never hurts to do some defensive programming and making sure users don't see too much exceptions in the use of the application.
In the example you mentioned, I would probably do a null-check and depending on the method, maybe throw a new ArgumentNullException.
A try-catch in this situation just feels a little 'dirty' in my opinion, but in a bigger scenario it might make more sense.
Back in the days I've learned throwing exceptions is an expensive operation (random link, check bottom of the page), so avoid them if possible.
Another thing which I don't really like about catching errors is, if you don't narrow them down enough, you could potentially catch an error which doesn't have anything to do with the piece of code you really want to check.
For example, if your application is 6-layers and you are calling some method like:
try
{
otherlayer.Method1();
}
catch(IOException ioEx)
{
//DoSomething
}
It is possible this IOException catches something which you didn't expect at first, so you will probably handle it wrong. (could happen if someone decides to change the other layers without your knowledge).
In summary:
I would advice against using a lot of try...catch
blocks in your code, only when they are really necessary and they are adding something usefull, or make sure your program flow will continue to operate.