[Mono-list] Exceptions and error codes.

Philippe Lavoie philippe.lavoie@cactus.ca
Tue, 25 Mar 2003 10:19:25 -0500

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

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.


-----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.


    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

    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.

Mono-list maillist  -  Mono-list@lists.ximian.com