I haven't done any measuring on code with/out Try-Catch, and also not investigated and read further on this topic yet. I think "double-managed" code would perform worse than "single-managed". Catching errors that would normally make the app crash and end should be adding some kind of layer between the code call and its invokation. Since performance is important for programming I wouldn't think such layer was permanent, ie without Try the layer would let app crash and with Try the layer would catch it. Just thinking out load, I would say there are different code invokation paths for exception catching code and code without this net.
Another difference, if you Try all code inside every method it is actually harder to control the flow of the application. An important note here; Exception handling should not be used to control the flow of the application, it is just a mechanism to escape special and somewhat predictable situations where app otherwise may crash because of bad input to a method or bad processing within a method. As said, catching all code is not a good plan, because this lets you skip any analyze of internal code, consequence is if exception occur app continues without you the programmer really knowing where and what went wrong, thus not seeing how this will impact next steps/blocks of code. This may in turn lead to exception upon exception and an malfunctioning application that may not stop but be totally out of control. Many exceptions are not notified to the user of the application, so the user is also unaware about the bad condition of the running application. To step back to the basic example of the corrupt "image", if user was told right away that the "image" was corrupt, a new correct "image" would have been loaded. In some cases such scenario is hard to cover, but knowing the code and try-catch sparingly and intelligent give you full control at all stages of code execution, both for what happened and what to come.
