There are a range of reasons your application may throw and catch exceptions; for example there may be cases where your code has to be prepared for certain exceptions that are unavoidable - such as a file being locked or network not being available. Even when you're ready to handle them they are still exceptions.
Loupe lets you associate exception data with a log message of any severity. The severity should indicate the judgment of your application on the situation, not merely the presence of the exception. In the case of an exception you're prepared to handle without user intervention you probably want to log it as an Informational message. If it's something suspicious but not going to alter your control flow then perhaps Warning is best.
The key idea is that exceptions are data - and you should log them along with information describing the circumstances of the exception and, more importantly, what your application is going to assume it means. For example, if you assume a particular exception means that the file didn't exist and will need to be created put that in the log message. It will significantly help in troubleshooting because if a particular exception doesn't align with your assumption and action it will be clear from the log.
Loupe records the class, method, and (if available) the file and line number of each log message. Normally the location where the Loupe API was called is recorded. This works well for normal logging and for errors where the exception is being caught and handled at a specific point in your code.
This isn't nearly as useful for higher level exception handlers - ones that are placed to be sure an exception is caught before it forces the thread or process to exit. In this case (like an unhandled exception handler) where the exception was logged isn't interesting but where it was thrown from is very useful since that's where the problem started.
Loupe supports both methods of attribution for logging error and critical messages. The Log.Error and Log.Critical methods have overloads that take an exception and let you specify whether to attribute the log message to where it was logged or to where the exception as thrown. The Log.RecordException and Log.ReportException methods always attribute the log message to where the exception was thrown.