Actually tornado.util.import_object can raise several different exceptions (ValueError, IndexError, AttributeError, ImportError) in different cases. This is not so convenient to handle all of them. Of course, there are two ways to improve such behavior:
According to usage of this function in framework:
I implemented second approach. DocTest for function is updated so you can find all cases there.
Implement additional error handling in utils.import_object function
Returning None instead of raising an exception is a semantic change that needs to be matched by a check on the return value at every call site. I think that in general it's better for import_object to raise an exception than return None. It would be nice if it raised a consistent exception, but not necessary (and your change doesn't guarantee None on a failed import; it could still raise SyntaxError or any other error produced by top-level code in the imported module).
So, as far as first approach is preferable, I'll update this branch ASAP (actually I have both implementations).
P.S. Regarding to SyntaxError, I don't see problems here cause SyntaxError can be raised anywhere and we can't protect against it (and we even should not do this).
Merge remote-tracking branch 'upstream/master' into import-object
import_object will raise standard ImportError even in case of Value/A…
Done. Now we will get standard ImportError for "missing" modules.