Exceptions vs return codes : do we lose something (while gaining something else)?

how about:

for(int i = 0; i < n; i++)
{
  try
  {
    myCall();
  }
  catch(Exception e)
  {
    Log(String.Format("Problem with {0}", i));
  }
}

I think you've got it wrong, and its not surprising as many other people do too.

Exceptions are not to be used for program flow. Read that again, its important.

Exceptions are for the "whoo, that's wasn't supposed to happen" errors that you hope never to see at runtime. Obviously you will see them the moment your first user uses it, which is why you have to consider the cases where they might happen, but you should still not try to put code in to catch, handle and continue as if nothing had happened.

For errors like that, you want error codes. If you use exceptions as if they were 'super error codes' then you end up writing code like you mentioned - wrapping every method call in a try/catch block! You might as well return an enum instead, its a lot faster and significantly easier to read error return code than litter everything with 7 lines of code instead of 1. (its also more likely to be correct code too - see erikkallen's reply)

Now, in the real world, it is often the case that methods throw exceptions where you'd rather they didn't (EndOfFile for example), in which case you have to use the "try/catch wrapper" anti-pattern, but if you get to design your methods, don't use exceptions for day-to-day error handling - use them for exceptional circumstances only. (yes, I know its difficult to get this kind of design right, but so is much of design work)

I don't like the "now, with exceptions..." expression.

Exceptions are a tool that you have for using it in your programming - if you think that it is the best option, use it, otherwise, don't.

I follow a personal rule of not throw any exceptions that I can avoid throwing, in internal code. For an API of a publicly available DLL, precondition checks should be left enabled and trigger exceptions if they fail, yes; but for internal logic, I seldom (if ever) include exceptions in my design. Conversely, when I'm using some function that documents that it will throw if some bad situation happens, I tend to capture the exception inmediately - it is an expected exception, after all.

If you think that your non-exceptional alternative is better - stick to it!