Is it possible an Exception object raising another exception due to its internal error?

Is it possible an Exception object raising another exception due to its internal error?

Assume in try-catch we instantiate Exception object, is it possible the instantiation raising another开发者_如何转开发 exception? If yes, we must nest infinitely try-catch blocks that looks so funny.

---

In short, the answer is yes, it is possible.

For example - if the exception class requires a large object to be initialized as a field, but there is not enough memory to allocate it, you will get an exception object that would throw an OutOfMemoryException.

Exceptions are like any other class and can in themselves throw exceptions. There is nothing in the language that disallows it.

I would say, however, that throwing exceptions from an exception class it bad practice and should generally be avoided.

---

Update: (following updated question)

If you are instantiating an exception object in a try block, the catch will catch it (assuming it catches the appropriate type of exception). If you are instantiating it in the catch block, you may want to do that in a nested try{}catch{} - this is quite normal for code used in a catch block that can throw exceptions.

As others have said - some exceptions should not be caught (for instance OutOfMemory or unexpected StackOverflow), as you don't have a way to deal with them.

---

Yes - certainly it is possible for an exception itself to raise an exception.

However, most (not all) of the framework exceptions are pretty lightweight things with very little internal logic, so the average exception probably doesn't have a lot of scope to generate exceptions itself.

Is this a framework exception you are seeing this behaviour with? Can you give us some details?

A quick look at the internals of the exception with a tool like Reflector may well help you spot what, if anything, is going on.

---

Yes, it's possible although not very typical. If the exception being thrown has an error in the constructor, or depends upon missing classes, then it itself throw an exception.

It's easy to test this: create your own exception that attempts to call a method an null reference. When you instantiate the exception, it will throw a NullReferenceException.

---

Yes. This is possible.

But I wonder why one would ever want to do this ? Exceptions are just for communicating errors so practically by design, they cannot have any serious code or logic running within them that can cause an exception. If you're argument is, you might want to log the exception into database or disk which might cause an exception in some conditions, then I'd not even agree to that since the exception should be logged in the catch block.

---

If you are thinking that the exception object should attempt handle the situation and throw another exception if it couldn't you are incorrect.
The catch block should handle the incorrect situation and throw the exception further away if it can't do so.
Example:

try
{
   BigResource r = new BigResource();
}
catch(BigResourceException e)
{
   bool cannotHandle = false;
   // Handle exception here

   if (cannotHandle)
      throw e;
}