When a caller makes a call to a callee, exception's are used to inform the caller that something different has happened so that he could change the flow of the program if required. In that sense, exception is not an error but a predictable outcome at layer of abstraction it was raised from. Most programming languages stop the execution if caller has no handlers to handle that situation.

Bjarne Stroustrup puts it like this in his article,

The author of a library can detect errors, but does not in general have any idea what to do about them. The user of a library may know how to cope with such errors, but cannot detect them or else they would have been handled in the user’s code and not left for the library to find.

But what about things that can't be detected either because it was not reported or the detection mechanism was weak, probably in the hardware?

I have have seen at least two types of behaviors:

  1. The entire system just hangs. Hardware malfunction, faulty bios etc. are examples of such failures. Would it be fair to say that the error happened at a level where there was no recovery (like redundant hardware) mechanism, so the entire system failed?
  2. The system recovers for the next operation reporting that something unknown happened like "An unknown exception occurred! ". For example, a web-server that runs in a infinite try-except loop is an example of such a scenario. In this case, the problem happened at a level where the recovery mechanism's job was to just report and continue?

I know this is a bit vague, but my main doubt is what happens when a completely unknown stuff happens! I am not talking about FileNotFound, or PermissionDenied etc, but something nasty probably at hardware level that is yet to be discovered or documented etc?

  • 1
    Exceptions are one way to handle exceptional situations, that is rare errors. Though in some languages they are also used for not so rare things. Two other ways are traps/signals and error-codes. Also, some exceptional situations mean a breakdown of the programs basic invariants. And in that case, the best thing to do might be a straight abort to avoid compounding the catastrophe. – Deduplicator Jan 21 '19 at 13:53
  • 1
    Exceptions has several meanings: "task cannot be completed", "exception has to be thrown because the code (interface, API, contract) is written in a way that throwing exception is the only way to let the caller know", and "if the exception handled properly, the software can recover itself to a known good state". Hardware induced failures do not meet the third criteria - when hardware induced failures occur, it is assumed that the software will perform bizarrely, producing wrong, or nearly correct but wrong, or impossible results. Triple redundancy with crosscheck is the only way to handle. – rwong Jan 21 '19 at 20:04
  • 1
    How would you except the caller to handle a power outage? Some things simply are not under the control of the program, neither the caller nor the callee. – Polygnome Jan 23 '19 at 10:01
  • 1
    @Nishant I don't understand what you are saying? The program itself has no way to influence the power supply, at all. And in most cases, it doesn't even have the ability to notice that power isn't there. the program just fails. Yes, you can have systems in place that offer continuous power. but that system isn't part of the program. programs usually have assumptions about the hardware they are running on. Like an API is a contract between callee and caller, the hardware offers a certain contract. If the contract is broken, all kinds of stuff can happen. – Polygnome Jan 23 '19 at 10:22
  • 1
    @Nishant There are scenarios where you plan for hardware to fail, e.g. space applications and create your program in such a way so that you can deal with e.g. bit flips. Ethernet drivers do the same, they are tolerant (to a certain degree) against faulty bits. But if the hardware just does some random stuff you didn't anticipate, then all kinds of stuff can happen. I am not sure why exceptions have anything to do with it? You can probably write a BitFlippedException if you like and your program has low-level enough hardware access, but what would be the point of that? – Polygnome Jan 23 '19 at 10:24

Your question is a bit vague, but let's focus on the case where an error may happen in a system, but the library or infrastructure you are using is not able to detect it properly and so not able to throw any exceptions about it (it seems the other answerers did not address this so far).

For example, because of cosmic rays, there is a certain probability for bit-flips in memory when a system just runs over years, so it is not unlikely for almost any software system to run into such an "unknown situation", at least when the software is used often and long enough.

So first you have to decide if you really want to deal with such cases. For many non-crititical systems, even a program which "hangs" or "crashes" from time to time can be perfectly acceptable, depending on what "time-to-time" means (once per month/per quarter/in ten years?), and how large the financial loss is when the system has a malfunction.

However, if you are creating software for flying an aeroplane or a space shuttle automatically, your measures are probably different. You often cannot deal with the mentioned issues directly (for example, by changing your exception handling strategy), but that does not mean there is nothing you can do about them. For such cases, the key tactics are redundancy and to avoid single point of failures.

For example:

  • You expect a certain hardware-interoperation to stop the main process? Install a watch dog process and implement a restart procedure for such cases.

  • You want to make the sytem keep working in case a of a complete hardware failure? Have a second set of hardware prepared, and implement a fail-over process which gives control to a backup system automatically.

  • You suspect a library to corrupt some data secretly under certain circumstances? Add additional data validation checks, checksums or error-correction code, even if that seems to be redundant. Provide an automatic backup-restore mechanism in case its worth it.

  • You expect your system to have bugs in a critical calculation routine? Let the routine be implemented by three different persons, indepently from each other, then always call all three implementations and accept their results only in case they are all three identical.

I think you got the idea. Making systems fail-safe is a complex discipline, which typically involves software, hardware, organizations, and people.

| improve this answer | |
  • 1
    … and a realistic and adequately-defined acceptable level of risk. Without the last, one will either waste money, or stop too short. – Deduplicator Jan 21 '19 at 22:45

Say you are trying to read a file from a network storage.

In your program, you assume the network is available, the file exists and you can read the file. You would wrap your code in a try statement and then you can test for various exceptions you know that could occur. You don't expect them to happen, but in exceptional situations they could. For example an IOException or FileNotFoundException.

In reality, these aren't the only two exceptions that can occur, therefor we often catch the other, unknown, exceptions in a catch all statement.

For example something like this:

    // Do stuff
catch (FileNotFoundException exception)
    // Handle FileNotFoundException (note that this is a subtype of IOException)
catch (IOException exception)
    // Handle IO Exception
catch(Exception exception)
    // Handle any other type of Exception

So now, you can determine what your program should do in case any of the known or unknown exceptions occurs.

You might want to handle the FileNotFoundException with an immediate return to the user, but any other IO errors (that could be temporary) with a retry mechanism.

The same applies for exceptions that aren't specifically handled. Let's say an InvalidCredentialException or an OutOfMemoryException. Both of these end up in the same generic Catch branch, so they will both be handled the same. How any exception that isn't caught is handled, is up to the creator of the method to determine. This is likely the place a generic message like "unknown error occurred" is coming from.

| improve this answer | |

Imagine for a second that a library is a black box. It has inputs and outputs. Some of these outputs are, in a real sense, exceptions. Generally a library shouldn't try to handle errors unless it is something which can be handled reasonably by the library itself.

Also your program is a black box in a sense. Your black box contains the smaller black box of the library. You pass it input and receive the output, and you use this to influence the inputs and outputs in your black box. If something were to happen in your black box that would result in an unexpected exception, how would you handle this?

It could happen that you run out of memory or the network cable was detached from the computer after you had established a connection. These types of problems can't really be dealt with but more importantly, they can't really be anticipated. For every such problem, it is generally ill-advisable to catch and ignore. You generally want to make it known to the system, the caller, and eventually the programmer himself that something has gone wrong and to report details so that it can be hopefully handled in the future.

So in that case, you catch and rethrow the exception. When the library throws an unknown exception, this is all that it is doing. It is saying, "situation is serious FUBAR here! Aborting!" Like any exception where you can't handle or don't know the cause, you should simply let the exception continue on its way up. Of course you could catch the exception, but you very likely don't want to cover up an unknown error of the library anymore than you'd like to cover up an unknown error in your own program.

Every other error thrown by the library should have its reasons, and you may or may not decide to handle them. Ultimately, your program should handle only errors which it can handle, no more.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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