Error catching, .NET vs Java EE
Author
Hello,
I wonder why no C++ source, that relates to game programming, I have seen so far never uses the Try { } catch { } error trapping. Is the use of try {} catch{} reducing the performance of a C++ application ?
Also recently I’ve seen the Java EE which introduces the web services and also has servelet , jps , enterprise javabeans support etc. Comparing it with the .NET framework, I found it much more difficult to work with. I am no Microsoft fun but clearly Microsoft has done much better work than sun.
I’d like to hear comments of others between the .net and java EE.
Quote:Original post by Kensha
I wonder why no C++ source, that relates to game programming, I have seen so far never uses the Try { } catch { } error trapping. Is the use of try {} catch{} reducing the performance of a C++ application ?
I assume that exceptions will slowly become the norm in all programming communities as the performance costs and software quality needs to clients increase.
In C++ try catch blocks do have some performance costs, but generally the costs only occur when an exception is actually thrown, but it really does depend on the exact compiler. Other C++ costs related to exception handling include RTTI being turned on to handle exceptions which can potentially make executables larger. Apparently some compilers will add additional code if exception specifiers are used.
I heard stories a while ago about exception specifications having run-time implications for .NET and java - but I haven't been writing code that needed to be fully optimised for those platforms, so I'm not sure how correct they are.
As much as I hate to say it, most game development is not defensively coded.
Most game programmers code as if speed is the only thing that matters. They base their premature optimizations on hand-me-down advice that was last valid on the 8088, or run off willy-nilly without actually testing to see what happens.
I can only speak to .NET exceptions, as I was a .NET developer prior to joining Ritual. In .NET, using Try/Catch is essentially free. However, throwing exceptions is extremely expensive.
The lesson: use Try/Catch for defensive programming. Do not use Try/Catch for normal program flow.
Most game programmers code as if speed is the only thing that matters. They base their premature optimizations on hand-me-down advice that was last valid on the 8088, or run off willy-nilly without actually testing to see what happens.
I can only speak to .NET exceptions, as I was a .NET developer prior to joining Ritual. In .NET, using Try/Catch is essentially free. However, throwing exceptions is extremely expensive.
The lesson: use Try/Catch for defensive programming. Do not use Try/Catch for normal program flow.
Kensha, what was disappointing about the Java EE exceptions that .Net did a better job of?
...
When you're writing C++ code, frequently you use classic C-like error handling mechanisms and/or use the OS error handling mechanisms which provide more useful information than the portable C++ try/catch handling.
Most C++ code has a different mindset about exceptions, they are only thrown if something catastrophic happens. Checks are made in advance to verify an operation will succeed, or if that's not possible (such as with many file operations) then error codes are returned as opposed to throwing.
The try does have performance impact as it roughly correspond to the legacy C setjmp call, throwing an exception correlates to the longjmp call, and exiting a catch block need to tear-down the setjmp bookkeeping (when an exception is *not* thrown). If there's an exception specifer (and the compiler supports them) it must filter any expcetions thrown to determine whether to pass them on or abort and invoke 'unexpected'.
...
When you're writing C++ code, frequently you use classic C-like error handling mechanisms and/or use the OS error handling mechanisms which provide more useful information than the portable C++ try/catch handling.
Most C++ code has a different mindset about exceptions, they are only thrown if something catastrophic happens. Checks are made in advance to verify an operation will succeed, or if that's not possible (such as with many file operations) then error codes are returned as opposed to throwing.
The try does have performance impact as it roughly correspond to the legacy C setjmp call, throwing an exception correlates to the longjmp call, and exiting a catch block need to tear-down the setjmp bookkeeping (when an exception is *not* thrown). If there's an exception specifer (and the compiler supports them) it must filter any expcetions thrown to determine whether to pass them on or abort and invoke 'unexpected'.
Author
Hey I didn't say that I have any problem with the java EE exception handlers. Sorry if I didn't make it clear. I just said that the java EE and the .Net do exactly the same job and .NET is faster and easier to work with.
writing bad code is easy. Write clean, proper code the first time, and if it's too slow, then substitute it for the really bad stuff.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
