An exception is an "exception to the normal flow of your application". By definition all exceptions are errors so I would flag any exception as an error. There is no other property that indicates how severe an exception is because an exception, by definition, is an unexpected error.
What you really have to decide is which exceptions are recoverable and which aren't. That is really what determines how to respond and unfortunately it completely depends upon your app's needs. For example an error opening a file is recoverable if you asked the user for a file and they gave you a bad one. There is no reason to log that one, just tell the user they messed up. Similarly if you're trying to open a file containing the user's custom settings but you cannot find the file then that is also recoverable (just use the app defaults). But if your application relies on a data file that ships as part of your app and you cannot find it then that may be a fatal application error that you need to log. The user is unlikely to be able to recover from that unless they do a repair.
The way you should "handle" exceptions is using a try-catch. Wrap the code you can handle errors from (such as opening a user-specified file) and specify the exception types you can handle (e.g. FileNotFoundException
). Then respond to each exception type appropriately. If you cannot handle an exception then do nothing and let the system handle it. The system will log the exception to the event log and crash the app with WER. This is preferable. If you need custom exception logging then you'll need to get notifications when unhandled exceptions occur (see SetUnhandledException) but note that your app is terminating at that point.
void OpenUserProvidedFile ( string filename )
{
try
{
OpenFile(filename);
} catch (FileNotFoundException)
{
MessageBox.Show("The file could not be found.");
} catch (IOException)
{
MessageBox.Show("An error occurred trying to open the file");
}; //Let other exceptions filter up through the app
}