Best Practices For Handling Deadlocks In Sql 2005 And Beyond

Greetings
I have a scenario where a table's after insert & after update triggers write to a history table. On this particular table, the history rows are quite small, so the occassional deadlock condition is inevitable.

In SQL Server 2000, I taught the application guys to handle these kinds of exceptions themselves, sleep a second, and retry. In 2005 (and I assume 2008) we now have TRY CATCH in T/SQL.

What are the pro's and con's of catching deadlocks in your T/SQL code (triggers or sprocs) .vs. the "old way" of catching it at the application level? I'm sure this has been discussed before, but search returns a lot of unrelated postings...

I'm thinking it's better to catch this at the application level, under the assumption that it's better to make the client(s) do the work than the database, but I'm sure there are considerations I'm not taking into account here. What experiences do you folks have to share on this?

Thanks!!