[Mono-list] Exceptions and error codes.

[Thong (Tum) Nguyen]

Hi Phil,

I totally agree.  Those are points I didn't make so clear :-). 

^Tum

> -----Original Message-----
> From: mono-list-admin@lists.ximian.com [mailto:mono-list-
> admin@lists.ximian.com] On Behalf Of Philippe Lavoie
> Sent: Wednesday, 26 March 2003 3:28 a.m.
> To: Philippe Lavoie; Miguel de Icaza; tum@veridicus.com
> Cc: mono-list@lists.ximian.com
> Subject: RE: [Mono-list] Exceptions and error codes.
> 
> Just to add to what I just wrote.
> 
> My philosophy with code is that most of the cost is with fixing bugs.
If
> you write maintainable code (readable using consistent patterns
> throughout) backed with good unit tests, then you are minimizing a lot
> the cost of software development.
> 
> In open source, it doesn't really matter as the code is written mostly
> by one and for one. However in large projects, code which makes it
easy
> to fix and add stuff is worth a lot more then a speedup of 5 or 10
> assembly lines.
> 
> My thoughts (which are worth about 1.2 cents American right now)
> 
> Phil
> 
> -----Original Message-----
> From: Philippe Lavoie
> Sent: Tuesday, March 25, 2003 10:19 AM
> To: Miguel de Icaza; tum@veridicus.com
> Cc: mono-list@lists.ximian.com
> Subject: RE: [Mono-list] Exceptions and error codes.
> 
> 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:miguel@ximian.com]
> Sent: Sunday, March 23, 2003 10:43 PM
> To: tum@veridicus.com
> Cc: mono-list@lists.ximian.com
> 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  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
> _______________________________________________
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
> _______________________________________________
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003