My question is specific to php, but i think it can be useful in other languages.
I log into a table all the exception a code can throw:
try{
//Some code
} catch (Exception $e) {
$log = new Log(basename($_SERVER['PHP_SELF']), $_SESSION['id'], LogType::EXCEPTION, $e);
try {
$log ->addLog();
} catch (Exception $e2) {
//
}
}
The function addLog insert the exception informations into a database.
But (by example if the connection with the database is lost) this function can throw an exception. I can’t see what i have to do with this exception except ignoring it.
I know ignoring exception is a bad practice, but what can i do in this particular case?
If there is no problem to ignore it, is there a better way to indicate that this exception should not be taken into account?
4
Whatever you do, don’t swallow the exception. If something is broken, you need to know about it. Swallowing an exception is only reasonable in very rare circumstances.
When you catch an exception, you should try logging it into a data store (database, event viewer, whatever works for you), so that somebody can then go and look in a single place to see all the exceptions.
If logging fails, revert to a simpler logging mechanism that is not dependent on a network resource. I normally log to a text file and then ask the user to send me a copy of the file.
Finally, you should let the user know that something went wrong. You may choose to display the full stack trace or just a simple error message. Displaying a full stack trace to the end user is not recommended, as it’s a security risk. I normally display a user-friendly message that prompts the end user to contact support.
On a side note, I’ve also seen a logging mechanism where the client would submit error details to the logging service over HTTP. If the service were not available, the client would retry logging three times before failing and reverting to a simpler logging mechanism.
2
You should definitely react on that exception.
How you do that is up to your context. If writing logs to a database fails, probably it is the same db the application uses, which is probably down. Thus this could be a good time to write an e-mail to an admin. Which, on the contrary can make your mail-server quite busy, and/or also fail.
Logging to a file is a good idea. However, if you expect that case never to happen, you need raise attention to that file somehow in such a case.
If it is an important application you may want to think about monitoring it (Nagios, for example, is a monitoring tool). Those tools usually are capable of continuously parsing log-files for errors.
I had a function as fallback for logging to file as @CodeART and @Andy sugested
function log(Exception $e) {
$file = fopen('log/error.log', 'a+');
if ($file !== false) {
fwrite($file, $e->getMessage() . "rn" . $e->getTraceAsString());
fclose($file);
}
}
You could call it within the second catch. To use it you should configure your environment and make sure the script was write permission on your log directory