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:

 //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?

  • 1
    How would you know your logging is broken if you ignore them? You would think that things are OK - both that you are getting no exceptions and that the logger is working.
    – Oded
    Commented Apr 29, 2014 at 16:04
  • You're totally right, i'll never know. But if I have to log the exception on logger with an other way, this new way can throw exception too... It's an endless cycle, how can I manage that?
    – Getz
    Commented Apr 29, 2014 at 16:11
  • Assuming there's a chance that the logger can recover then you can keep a list of log entries that couldn't be logged (you'll likely have to limit the number of entries). When the logger recovers then log the entries that are in the list. Alternatively, maybe write the entries to a file. If once this error occurs there is likely no chance it will ever recover then it sure seems like you should find some way to notify the operator. Also, your addLog method should be where the log exception is caught, not every place that is trying to log something.
    – Dunk
    Commented Apr 29, 2014 at 16:23
  • possible duplicate of Error handling - Should a program fail on errors or silently ignore them
    – gnat
    Commented Apr 29, 2014 at 19:35

3 Answers 3


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.

  • 1
    I agree fully, you should use a local file as a failsafe for any network resource failures. Commented Apr 29, 2014 at 17:15
  • Yeah so what if every logging mechanism fails? E.g. a log file could have the wrong file permissions. Any fallback logic should already be part of the logger object, so I would say this question is about the case where it fails..
    – donquixote
    Commented Dec 20, 2016 at 5:23

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() . "\r\n" . $e->getTraceAsString());

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.