I doubt whether it would be useful to have a common place to log errors.
What do you want to achieve by this - code reduction?
Image an Exception called InvalidFileFormatException that could occur in your application whenever you try to open a file whose format is not as expected. A global exception handler could log this. Your logfile would then read something like:
[Yesterday...] The file format is invalid: InvalidFileFormatException. StackTrace: ...
But what do you gain by this information? Okay, I admit that if there's only one call in your whole application that can lead to this Exception being thrown then everything is fine. But what if there are multiple calls to the same method or if other called methods throw the same exception?
You have to rely on the Exception's detailed message, but unfortunately if it comes to Exceptions thrown by the Runtime, you cannot influence the messages. Wouldn't it be nicer to have something like
string fileName = @"C:\Users\stackoverflow\Documents\file.frk";
try
{
FreakingObject fo = freakingObjectConverter.ReadFromFile(fileName, FreakFormat.AutoDetect);
}
catch (InvalidFileFormatException iffe)
{
MyLogger.LogError("File " + fileName + " had an invalid format:", iffe);
}
In the example you at least get the information about the malformatted file. You could easily create more complex examples (HttpRequest etc.) where you can add very useful information to your log if only you were aware of the context the Exception was thrown in.
Small hint on the try-catch around Application.Run(...)
: keep in mind that whenever you reach the catch block, your application will exit if you do not respawn the main form or do anything else.