Classic interview question. What would you change in your favorite programming language?

I've been struggling with this question for a few days... It's really a tough one! I can't even say which is my favorite language! Yet I don't think I can claim to understand a language (let alone my favorite one) unless I can say something wrong about it! So here's my answer:

I would change the way python handles error management. I'm talking about exception blocks (my problem is not tied to python in particular, I am simply generally unconvinced by the exception model). Coming from a C environment, I am used to check manually for errors. That means that each time I call a function, I test the return code. On Unix, it's pretty standard, return code is 0 if success, a (documented in the man page) integer in case of error. All I have to do is something like this:

n = function(args);

if (n == ERROR1) exitgracefully();
else if (n == ERROR2) printmsgclosefileandexit();
else {
 continue();
}

Clearly, writing as many if (n == ERRORX) as there are possible errors, can be a pain, and extra lines mean extra bloat to your code. This is exactly the problem exceptions tried to solve. In itself, exceptions is a great idea, but I feel it encourages poor error checking. Take a look at this:

try {
  f(g(...));
}
except IOError {
  ...
}

There are two problems I see in this code:

1- What function is raising the exception?

Can you tell with absolute certainty where the error comes from? Is it f() or g()? What you actually do when catching the exception varies greatly depending on the error that raised that exception. A good code will probably prompt you to catch multiple exceptions (see parag. 2) but how often do you come across exhaustive exceptions? Almost never right?

2- What about the other errors that can occurr?

Is IO the only exception possible? Can you tell without a doubt if all exceptions are caught or not? One more time, how exhaustive is your error catching? Here's the issue: exception abstract error management, notably the 'raise' mechanism. An uncaught exception at this level "might" be caught by any higher order function. That seems easy and simple to avoid when writing a project from scratch. But try actually doing maintenance for a large code base. How can you debug an exception catch, if it's caught three or four levels higher?

Surely these weaknesses in the exception mechanism are not inherent, and there is a way to do good error handling with it. However it encourages lazyness and lack of exhaustivity. It is not uncommon to find bad style in exceptions.

Finally about Python, the issue is more of a community one. It is clear that community relies heavily on the (otherwise excellent) official documentation. Very little emphasis is put on covering all the exceptions that a function can raise, so generally not everyone will catch them all. Comapred to a Unix man page of a function, where every return code will be largely documented and very much put forward.

For those of you still reading, further info can be found in this excellent paper by Laurence Tratt. I especially recommend reading his proposal for an error handling system that solves the problem of rigid C-like checking return values while still going better and over the "weaknesses" of exceptions.