The error handling has to be done both at the remote server and at the local server. From MSDTC's perspective, the two or more servers (involved in a distributed transaction) may not handle errors in an identical manner (even between two different versions of SQL Server). Even worse (no offense intended), one server could be Oracle and the other server could be SQL Server. In short, MSDTC was not designed solely for SQL Server's use.

Untested by me, but if Server 02 is a SQL Server, you could instead execute a stored procedure that was created on Server 02. Try...catch error handling can then be done within that stored procedure (1205, 2627, etc). Alternative/additional features to consider are REMOTE_PROC_TRANSACTIONS and XACT_ABORT. If Server 01 and 02 are both SQL Servers, I expect uses of a stored procedure to mean Server 02's distribution statistics cannot be harnessed by/are not useful to Server 01. I am unsure how/whether MSDTC can handle passing a table as a parameter to a stored procedure (via a user-defined data type).

A little off topic, but even for a one-server transaction, a try...catch block will fail to catch sufficiently high severity errors. And a few years ago I saw a linked server created on a production server to a test server "cause" a production failure: The production server experienced massive blocking at a time when the test server was being tested for "its" response to a network failure ... ;). A little more on topic: No matter what you do, there will still be times when both systems must be checked for errors :).