Charles Hixson wrote in message <3B816D1F.80309@earthlink.net>...
>One thing that needs to be clear:  Is an exception for handling an expectable error?  What's the run-time cost of handling an exception? This isn't always easy to find out, and it could have a big effect on how they would be used.  (Someone once told me that it took 1000 times as long to process an exception as to process a branch.  If this is true, then using them for "exceptional case" handling is ... less desireable.


The runtime penalty for throwing an exception is large. Therefore, they should only be used for *exceptional errors*. Sometimes this requires rethinking what an error is. For example, polling a device in a loop to see if it is ready yet is not an error if it is not ready. It is only an error if it is *assumed* to be ready.

John Carney wrote in message <9ltbbg$20mh$1@digitaldaemon.com>...
>As an aside, I do recall reading somewhere that in Java, the following
code:
>
>    for (i = 0 ; i != anArray.length ; i++)
>        doSomething(anArray[i]) ;
>
>could be written faster as:
>
>    try
>        {
>        i = 0 ;
>        while (true)
>            doSomething(anArray[i++]) ;
>        }
>    catch (ArrayBoundsException &x)
>        {}
>
>Don't quote me on that - it was a long time ago and may be complete bollocks.


The reason for that is because inside the loop there's a check for the array bounds in addition to the check on the loop bounds. Eliminating one of the redundant checks can doubled the speed of the loop.

In D, array bounds checking can be turned on and off (unlike Java, which guarantees it is on), so the above loop is invalid D.

> I'm going to rethink it. I do read all of the arguments <g>. -Walter

Can't ask fairer than that :-)

Cheers,
John Carney.

It occurs to me that strict exception specification might make the exception handling code less costly and complex (from the compiler perspective).  I assume that unlimited exceptions (like in C++) means that the compiler has to implement some sort of runtime type identification to compare the thrown type to the list of caught types.  It seems that with strict specification, the exceptions could by specified by an ordered numbering.  That is, when you throw an exception, you throw both a value (pointer, I assume) and an integer; the integer corresponds with the exception type's order in your function declaration.  Thus:

void foo() throws A,B,C;

means that if foo throws A, the type parameter will be set to 0, B it is 1, C it is 2.  The catch block can look up these values.  Consider:

void bar() throws A,C; // calls foo()

In the catch block in bar(), if it sees the type as 0, then it just rethrows it.  If the type is 2, it changes the type to 1 and rethrows (since C is exception 1 in its declaration).  If the type is 1, then it jumps to the handler code.

This seems like something that could be handled very simply with a compiler-implemented switch block.



My understanding of exceptions is like that of garbage collection; I understand the concept but don't know how it is implemented, so maybe I'm totally confused.  Thoughts?

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <russ@deming-os.org> wrote in message news:3BB46A58.88D44384@deming-os.org...
> My understanding of exceptions is like that of garbage collection; I understand the concept but don't know how it is implemented, so maybe I'm totally confused.  Thoughts?

The best way to understand it is to write some EH code in C++, compile it, and run the output through OBJ2ASM. D implements it the same way.

Also, there will only be EH overhead in D for functions that have try blocks in them.