Hi Phil, I totally agree. Those are points I didn't make so clear :-).
^Tum > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:mono-list- > [EMAIL PROTECTED] On Behalf Of Philippe Lavoie > Sent: Wednesday, 26 March 2003 3:28 a.m. > To: Philippe Lavoie; Miguel de Icaza; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > 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; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > 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:[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 > _______________________________________________ > Mono-list maillist - [EMAIL PROTECTED] > 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 _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
