Layers and exceptions
-
Well I use C# and VS 2005, but that shouldn't matter. I caught an Exception and viewed the StackTrace and TargetSite values in the Watch window and both showed the method that threw the Exception. Now I think I'll write up a little sample program...
Hopefully, you'll find a way to help me see the info that I'm not currently able to see. However, in the catch handler, it is the stack trace of the throw point that matters, not the stack trace of the catch block itself. Further, what you'd really like to have is to be able to put a breakpoint in the catch handler and have the debugger understand the throw point and show you the variables in the stack frame of the throw point. Obviously, you can cause the debugger to stop when the throw occurs, but in VC++ 2003, you are not able to filter out throws that you are not interested in. For example, the CFile class throws exceptions for lots of silly reasons. If tell the debugger to stop on all throws, I'm constantly hitting throws which must be ignored -- and I don't know of any way to tell the debugger not to stop at at a particular throw point. If you know of a way to do that, please let me know.
-
Well I use C# and VS 2005, but that shouldn't matter. I caught an Exception and viewed the StackTrace and TargetSite values in the Watch window and both showed the method that threw the Exception. Now I think I'll write up a little sample program...
Here's a simple example. An Exception could be thrown (or passed along) by any of the methods, all will be caught and displayed by the Main.
namespace Template
{
public partial class Template
{
private static int
Div
(
string Op1
,
string Op2
)
{
return ( Div ( int.Parse ( Op1 ) , int.Parse ( Op2 ) ) ) ;
}private static int Div ( int Op1 , int Op2 ) { return ( Op1 / Op2 ) ; } \[System.STAThreadAttribute\] public static int Main ( string\[\] args ) { int result = 0 ; try { System.Console.WriteLine ( Div ( args \[ 0 \] , args \[ 1 \] ) ) ; } catch ( System.Exception err ) { System.Console.WriteLine ( err.Message ) ; System.Console.WriteLine ( err.TargetSite ) ; System.Console.WriteLine ( err.StackTrace ) ; } return ( result ) ; } }}
In this run Main encounters an error.
C:\>StackTest
Index was outside the bounds of the array.
Int32 Main(System.String[])
at Template.Template.Main(String[] args)In this run the Exception came from deep in the belly of .net
C:\>StackTest a b
Input string was not in a correct format.
Void StringToNumber(System.String, System.Globalization.NumberStyles, NumberBuffer ByRef, System.Globalization.NumberFormatInfo, Boolean)
at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
at System.Int32.Parse(String s)
at Template.Template.Div(String Op1, String Op2)
at Template.Template.Main(String[] args)In this run the integer divide threw the Exception
C:\>StackTest 1 0
Attempted to divide by zero.
Int32 Div(Int32, Int32)
at Template.Template.Div(Int32 Op1, Int32 Op2)
at Template.Template.Div(String Op1, String Op2)
at Template.Template.Main(String[] args) -
Hopefully, you'll find a way to help me see the info that I'm not currently able to see. However, in the catch handler, it is the stack trace of the throw point that matters, not the stack trace of the catch block itself. Further, what you'd really like to have is to be able to put a breakpoint in the catch handler and have the debugger understand the throw point and show you the variables in the stack frame of the throw point. Obviously, you can cause the debugger to stop when the throw occurs, but in VC++ 2003, you are not able to filter out throws that you are not interested in. For example, the CFile class throws exceptions for lots of silly reasons. If tell the debugger to stop on all throws, I'm constantly hitting throws which must be ignored -- and I don't know of any way to tell the debugger not to stop at at a particular throw point. If you know of a way to do that, please let me know.
The contents of the trace will depend on whether or not it's a debug build. But I assume that you're debugging a debug build.
-
The contents of the trace will depend on whether or not it's a debug build. But I assume that you're debugging a debug build.
Yep, debug builds for sure.
-
Here's a simple example. An Exception could be thrown (or passed along) by any of the methods, all will be caught and displayed by the Main.
namespace Template
{
public partial class Template
{
private static int
Div
(
string Op1
,
string Op2
)
{
return ( Div ( int.Parse ( Op1 ) , int.Parse ( Op2 ) ) ) ;
}private static int Div ( int Op1 , int Op2 ) { return ( Op1 / Op2 ) ; } \[System.STAThreadAttribute\] public static int Main ( string\[\] args ) { int result = 0 ; try { System.Console.WriteLine ( Div ( args \[ 0 \] , args \[ 1 \] ) ) ; } catch ( System.Exception err ) { System.Console.WriteLine ( err.Message ) ; System.Console.WriteLine ( err.TargetSite ) ; System.Console.WriteLine ( err.StackTrace ) ; } return ( result ) ; } }}
In this run Main encounters an error.
C:\>StackTest
Index was outside the bounds of the array.
Int32 Main(System.String[])
at Template.Template.Main(String[] args)In this run the Exception came from deep in the belly of .net
C:\>StackTest a b
Input string was not in a correct format.
Void StringToNumber(System.String, System.Globalization.NumberStyles, NumberBuffer ByRef, System.Globalization.NumberFormatInfo, Boolean)
at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
at System.Int32.Parse(String s)
at Template.Template.Div(String Op1, String Op2)
at Template.Template.Main(String[] args)In this run the integer divide threw the Exception
C:\>StackTest 1 0
Attempted to divide by zero.
Int32 Div(Int32, Int32)
at Template.Template.Div(Int32 Op1, Int32 Op2)
at Template.Template.Div(String Op1, String Op2)
at Template.Template.Main(String[] args)Yeah - that would be nice. I wonder if there is a way to get VC++ 2003 to dump the processing of the thrown exception so that by the time we get to the breakpoint on the in the catch handler, we can at least see the trace back to the throw point. I'll see if there is something I'm missing in output window from the debugger -- but I've looked before and couldn't find it. Of course, my wife says I couldn't find my nose on my face. I'll spend a little more time checking. Wish me luck.
-
Yeah - that would be nice. I wonder if there is a way to get VC++ 2003 to dump the processing of the thrown exception so that by the time we get to the breakpoint on the in the catch handler, we can at least see the trace back to the throw point. I'll see if there is something I'm missing in output window from the debugger -- but I've looked before and couldn't find it. Of course, my wife says I couldn't find my nose on my face. I'll spend a little more time checking. Wish me luck.
(I think I know where you'd like to find your nose.) Ahem, ahem... so anyway... If it's Managed C++ you should be fine (I guess) as it's a .net issue, not a language issue. In .net at least, when the Exception is instantiated it's populated with the stacktrace at that point. But it does appear that in a standard release build, the stack trace is not fully populated.
-
I agree completely that there is no magic solution. As for my comments about exceptions slowing things down, I have measured it myself with several compilers. Merely compiling with exceptions turned on causes between 5 and 25% slowdown in algorithms that access large amounts of memory to, say, exhaustively search a large in-memory data set. I do understand that this is a rare kind of program to be writing, but everything has its place. Sometimes exceptions really don't matter for performance -- for example if you are doing a lot of system calls. None the less, I really wish they hadn't been added to the language. Other people are getting to force their annoyances on me as a developer, and they don't don't even have to write good documentation explaining the exceptions. This could also be true with error codes -- but they are a lot easier to debug than exceptions given the limitations of the tools available to me. We'll just have to agree to disagree. Peace, Lowell
Hi: Error codes are obsolete and they must be elimated from new software develoment. Error code are ignored and all methods that invoque function with error codes must return error codes, this sucks !! Exception must be cached on BR and loged if you want. Thanks
La entrada es gratis, la salida vemos....
-
I agree completely that there is no magic solution. As for my comments about exceptions slowing things down, I have measured it myself with several compilers. Merely compiling with exceptions turned on causes between 5 and 25% slowdown in algorithms that access large amounts of memory to, say, exhaustively search a large in-memory data set. I do understand that this is a rare kind of program to be writing, but everything has its place. Sometimes exceptions really don't matter for performance -- for example if you are doing a lot of system calls. None the less, I really wish they hadn't been added to the language. Other people are getting to force their annoyances on me as a developer, and they don't don't even have to write good documentation explaining the exceptions. This could also be true with error codes -- but they are a lot easier to debug than exceptions given the limitations of the tools available to me. We'll just have to agree to disagree. Peace, Lowell
Lowell Boggs wrote:
causes between 5 and 25% slowdown
Then you should investigate what the problem is, there's no reason your code should be throwing that many Exceptions.
-
Lowell Boggs wrote:
causes between 5 and 25% slowdown
Then you should investigate what the problem is, there's no reason your code should be throwing that many Exceptions.
The point Lowell is trying to make is that simply compiling with exceptions enabled in C++ causes a 5% to 25% performance hit due to the overhead in function calls, stack manipulation and the inability for the compiler to optimize as well as it can without exceptions enabled. Even if not a single exception was thrown in the entire application, the compiler still has to allow for the possibility that one could be, and this makes it's job much harder and results in a loss of optimizations. Personally I think exceptions have their place, sometimes things beyond our knowledge or control occur, eg a memory access violation where the immediate calling code has no idea about what it should do to handle this kind of error or if the operation that failed is important enough to be fatal to the application. If it's just logging a trace log then who cares? If it's writing a bank account transfer then it's a big deal. This exceptional situation needs to be handled at a higher level where the intention of the code is apparent. I don't think undocumented exceptions should be thrown out of libraries though. Libraries should have a strict interface and exceptions should be well documented for all error conditions.
-
Lowell Boggs wrote:
causes between 5 and 25% slowdown
Then you should investigate what the problem is, there's no reason your code should be throwing that many Exceptions.
The code was not throwing ANY exceptions. The slowdown comes from using the C++ compiler options that enabled exceptions. In the microsoft VC++ compiler, exceptions are disabled by default and you have to use an option to turn them on. However, the point is mute at this point in time -- in order to use the STL on many compilers, you have to compile with exception support. Still, you want a function to be as fast as can be it should be declare in such a way that it does not support exceptions. This may not apply to interpretive languages which are fundamentally slower than compiled languages anyway.