You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "David Bertoni (JIRA)" <xe...@xml.apache.org> on 2005/03/06 22:22:55 UTC
[jira] Created: (XERCESC-1368) Catch-all handler are problematic on Windows
Catch-all handler are problematic on Windows
--------------------------------------------
Key: XERCESC-1368
URL: http://issues.apache.org/jira/browse/XERCESC-1368
Project: Xerces-C++
Type: Bug
Components: Miscellaneous
Versions: 2.6.0
Environment: Windows XP with Visual Studio .NET 2003
Reporter: David Bertoni
Exception handlers of the form "catch(...)" are causing problems in our product code on Windows, because they are catching hardware exceptions, such as access violations.
There is an article in the MSDN Knowledge Base that describes how this has changed between Visual Studio 6, and Visual Studio .NET:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core_exception_handling.3a_.default_synchronous_exception_model.asp
However, my experience with Xerces-C using Visual Studio .NET 2003 is that hardware exceptions (asynchronous exceptions, in the Microsoft parlance) are still being caught in Xerces-C in catch-all handlers. This is problematic because it interferes with normal diagnosis of hardware faults, and can lead to code being executed in Xerces-C when the system is in an unknown state. It is also a makes it difficult to write code that will behave the same on other platforms.
Looking into the code reveals multiple places where a catch-all handler resets some object (or some other similar behavior), then rethrows the same exception. I'd like to propose that we try to eliminate as many of these catch handlers as possible by replaces these actions with stack objects that perform these actions automatically whether or not an exception is thrown (auto_ptr-like behavior). This will also have the benefit of simplifying the code. From a "philosophical" perspective, I also think its better for code to catch the exceptions it's concerned with, and avoid catch-all handlers except when absolutely necessary.
I will attach a proposed patch for a class that does this sort of thing, and some modified code that uses this class. I would also like to see if anyone else has observed this behavior in their Windows applications.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
[jira] Commented: (XERCESC-1368) Catch-all handler are problematic on Windows
Posted by "David Bertoni (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESC-1368?page=comments#action_60407 ]
David Bertoni commented on XERCESC-1368:
----------------------------------------
First of all, I think you are misinterpreting what I'm saying. I'm not proposing Xerces-C should add any platform-specific code, or some make some decision about how an application handles exceptions.
What I'm saying is Xerces-C as a library should:
1. Catch the exceptions it knows about and avoid gratuitously catching exceptions it doesn't.
2. As a result of 1, it should avoid using catch-all handlers solely for the purpose of releasing an acquired resource. This is better handled through RAII (resource allocation is initialization).
3. Neve use a catch-all handler that doesn't re-throw the exception that was caught. This actually happens in many places.
I really think this will lead to a library which is more portable. It will certainly lead to a library which has cleaner code.
> Catch-all handler are problematic on Windows
> --------------------------------------------
>
> Key: XERCESC-1368
> URL: http://issues.apache.org/jira/browse/XERCESC-1368
> Project: Xerces-C++
> Type: Bug
> Components: Miscellaneous
> Versions: 2.6.0
> Environment: Windows XP with Visual Studio .NET 2003
> Reporter: David Bertoni
>
> Exception handlers of the form "catch(...)" are causing problems in our product code on Windows, because they are catching hardware exceptions, such as access violations.
> There is an article in the MSDN Knowledge Base that describes how this has changed between Visual Studio 6, and Visual Studio .NET:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core_exception_handling.3a_.default_synchronous_exception_model.asp
> However, my experience with Xerces-C using Visual Studio .NET 2003 is that hardware exceptions (asynchronous exceptions, in the Microsoft parlance) are still being caught in Xerces-C in catch-all handlers. This is problematic because it interferes with normal diagnosis of hardware faults, and can lead to code being executed in Xerces-C when the system is in an unknown state. It is also a makes it difficult to write code that will behave the same on other platforms.
> Looking into the code reveals multiple places where a catch-all handler resets some object (or some other similar behavior), then rethrows the same exception. I'd like to propose that we try to eliminate as many of these catch handlers as possible by replaces these actions with stack objects that perform these actions automatically whether or not an exception is thrown (auto_ptr-like behavior). This will also have the benefit of simplifying the code. From a "philosophical" perspective, I also think its better for code to catch the exceptions it's concerned with, and avoid catch-all handlers except when absolutely necessary.
> I will attach a proposed patch for a class that does this sort of thing, and some modified code that uses this class. I would also like to see if anyone else has observed this behavior in their Windows applications.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
[jira] Commented: (XERCESC-1368) Catch-all handler are problematic on Windows
Posted by "Michael Fuller (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESC-1368?page=comments#action_60399 ]
Michael Fuller commented on XERCESC-1368:
-----------------------------------------
We've run into this issue elsewhere in code we maintain. We too make
extensive use of catch(...).
Under Unix, this isn't an issue because segmentation faults, div. by
zero, etc. get turned into signals. If an application wants to try
to cope with these faults, it should set up the appropriate signal
handler.
Under Windows, they get turned into pseudo-exceptions. The right way
to cope with these pseudo-exceptions is to use a vectored exception handler.
An application that cares about DIV0, SEGV, etc. should set up a
vectored exception handler:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/vectoredhandler.asp
(For older versions of Windows, you have to use _set_se_translator()
instead.)
In either case, it's an application level decision how to cope with
SEGV, DIV0, etc. Under Unix, you use a signal handler; or not.
Under Windows, you use a VectoredHandler; or not.
A library -- such as Xerces -- should *not* make that decision.
Any application that wants to can install a VectoredHandler;
The Xerces library shouldn't take that decision away from the
application developer.
I suggest we should close this issue as a "not broken, won't fix".
Michael
> Catch-all handler are problematic on Windows
> --------------------------------------------
>
> Key: XERCESC-1368
> URL: http://issues.apache.org/jira/browse/XERCESC-1368
> Project: Xerces-C++
> Type: Bug
> Components: Miscellaneous
> Versions: 2.6.0
> Environment: Windows XP with Visual Studio .NET 2003
> Reporter: David Bertoni
>
> Exception handlers of the form "catch(...)" are causing problems in our product code on Windows, because they are catching hardware exceptions, such as access violations.
> There is an article in the MSDN Knowledge Base that describes how this has changed between Visual Studio 6, and Visual Studio .NET:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core_exception_handling.3a_.default_synchronous_exception_model.asp
> However, my experience with Xerces-C using Visual Studio .NET 2003 is that hardware exceptions (asynchronous exceptions, in the Microsoft parlance) are still being caught in Xerces-C in catch-all handlers. This is problematic because it interferes with normal diagnosis of hardware faults, and can lead to code being executed in Xerces-C when the system is in an unknown state. It is also a makes it difficult to write code that will behave the same on other platforms.
> Looking into the code reveals multiple places where a catch-all handler resets some object (or some other similar behavior), then rethrows the same exception. I'd like to propose that we try to eliminate as many of these catch handlers as possible by replaces these actions with stack objects that perform these actions automatically whether or not an exception is thrown (auto_ptr-like behavior). This will also have the benefit of simplifying the code. From a "philosophical" perspective, I also think its better for code to catch the exceptions it's concerned with, and avoid catch-all handlers except when absolutely necessary.
> I will attach a proposed patch for a class that does this sort of thing, and some modified code that uses this class. I would also like to see if anyone else has observed this behavior in their Windows applications.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
[jira] Commented: (XERCESC-1368) Catch-all handler are problematic on Windows
Posted by "Michael Fuller (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESC-1368?page=comments#action_60410 ]
Michael Fuller commented on XERCESC-1368:
-----------------------------------------
Ok: I think I did misinterpret your direction, as I strongly agree
with the tenets espoused in your follow-up.
One quibble:
> 3. Never use a catch-all handler that doesn't re-throw the exception
> that was caught. This actually happens in many places.
"Never" is too strong; it is sometimes (in rare circumstances) right
to do this. However, if it's happening in many places that seems wrong.
Thanks for clarifying.
Michael
> Catch-all handler are problematic on Windows
> --------------------------------------------
>
> Key: XERCESC-1368
> URL: http://issues.apache.org/jira/browse/XERCESC-1368
> Project: Xerces-C++
> Type: Bug
> Components: Miscellaneous
> Versions: 2.6.0
> Environment: Windows XP with Visual Studio .NET 2003
> Reporter: David Bertoni
>
> Exception handlers of the form "catch(...)" are causing problems in our product code on Windows, because they are catching hardware exceptions, such as access violations.
> There is an article in the MSDN Knowledge Base that describes how this has changed between Visual Studio 6, and Visual Studio .NET:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core_exception_handling.3a_.default_synchronous_exception_model.asp
> However, my experience with Xerces-C using Visual Studio .NET 2003 is that hardware exceptions (asynchronous exceptions, in the Microsoft parlance) are still being caught in Xerces-C in catch-all handlers. This is problematic because it interferes with normal diagnosis of hardware faults, and can lead to code being executed in Xerces-C when the system is in an unknown state. It is also a makes it difficult to write code that will behave the same on other platforms.
> Looking into the code reveals multiple places where a catch-all handler resets some object (or some other similar behavior), then rethrows the same exception. I'd like to propose that we try to eliminate as many of these catch handlers as possible by replaces these actions with stack objects that perform these actions automatically whether or not an exception is thrown (auto_ptr-like behavior). This will also have the benefit of simplifying the code. From a "philosophical" perspective, I also think its better for code to catch the exceptions it's concerned with, and avoid catch-all handlers except when absolutely necessary.
> I will attach a proposed patch for a class that does this sort of thing, and some modified code that uses this class. I would also like to see if anyone else has observed this behavior in their Windows applications.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org