[Mono-list] Exceptions and error codes.

[Philippe Lavoie]

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=20
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=20

-----Original Message-----
From: Miguel de Icaza [mailto:miguel@ximian.com]=20
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'. =20

    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 =3D 0; i < one_million; i++){
		string line =3D readline ();
		try {
			v =3D 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