I think the original point made was that unless you have profiling information to back up any claim that "this part of the software" will slow you down. Then use a mechanism which will make your code more maintainable.
The example below clearly has performance issues. However if the function handle_number_argument below takes 100 ms to process, the 5 or 10 extra lines of assembly added by the try/catch becomes meaningless in terms of overall performance. You'd better spend your time improving that function then rewriting the parser of Int32. Sometimes, it could be best to improve the JIT to better handle embedded try/catch statements :) Just another way of looking at it. I don't think there is a "one and true" way. It's all a grey area when you start to mix performance / maintainability / readability / philosophy, etc. Phil -----Original Message----- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Sunday, March 23, 2003 10:43 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Mono-list] Exceptions and error codes. Hello, You do raise interesting points. The problem with exceptions is that throwing and catching an exception is an expensive operation. Using an exception as a mechanism to return a failure error, when failure is likely to happen is inefficient. Contrast `likely to happen error' with `exceptional condition: internal error, or unlikely error to happen'. Lets consider a sample: a program that uses Int32.Parse to detect whether an integer is available, or maybe a string command exists, and we are parsing, say, a million records: for (i = 0; i < one_million; i++){ string line = readline (); try { v = Int32.Parse (line); handle_numberic_argument (); } catch { ParseCommand (line); } } This is so bad, that you probably want to rewrite the code to pro-actively avoid parsing things that are known not to be integers. It is easy to turn an error-code API into an exception-throwing API with no performance loss. The opposite is not possible. Miguel _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
