Re: PATCH: Merge objc-improvements-branch to mainline

[Dietmar Planitzer <dave dot pl at ping dot at>]

On Thursday, September 25, 2003, at 01:55  AM, Nicolas Roard wrote:

> On 2003-09-24 18:24:44 +0000 Stan Shebs <shebs@apple.com> wrote:
>
> > This has been one of the most heavily-requested features for ObjC. 
> > While
> > it's true that it's syntactic sugar, so is for(), and yet few suggest
> > that it should be removed from C. For that matter, many programmers
> > contend that ObjC and C++ are unnecessary syntactic sugar too... The
> > rationale for adding exception handling, aside from the incessant user
> > requests, is that it is hard to get right manually, plus the manual
> > solution involves fooling around with explicit flow control in the 
> > form
> > of setjmp/longjmp, which you really want to hide whenever possible.
>
> What I don't understand, is that we _already_ have an exception system,
> so what was those requests about ?
> If NS_DURING/NS_HANDLER names scared programmers, well, we could
> define them as @try ... @catch :-)
> But I don't see what's so interesting with the new exception system, 
> apart
> to bring some incompatibilities ...
> Someone could explain it to me ?

I'm one of those people who have been asking for this feature for years 
and I'm naturally happy that we finally have it now.

The current macro based exception implementation has at least two 
significant disadvantages: (1) it is unsafe and (2) very inefficient on 
RISC CPUs.

It is unsafe because you as the developer must be aware that you have 
to mark variables which are to be used in both the try and catch block 
as volatile. Otherwise, your application might crash if it tries to 
refer to one of those variables in the catch block because the compiler 
might try to read the variable value from a register which naturally 
contains random data when the catch block is entered by a thrown 
exception.

It is highly inefficient on RISC CPUs like the G4 or G5 PowerPC chips. 
In the case of the G4 the NS_DURING macro, because it calls setjmp(), 
saves roughly 100 registers to a memory buffer. Those are 32 32bit 
integer, 32 64bit floating point and 32 128bit vector registers plus 
machine state registers. The situtation is worse on a G5 with its 32bit 
64bit integer registers.

It however, doesn't make the least sense to save 100% of the CPUs user 
state just because the catch handler might refer to 1 or 2 variables 
from the try block. It especially doesn't make sense to do this save 
operation no matter if an exception ever gets thrown or not. But this 
is exactly what NS_DURING is doing now - it always saves the whole user 
state although your code will hardly ever throw an exception. After 
all, exceptions are there for handling exceptional situations.

Exceptions are a flow control construct. This is one fundamental reason 
why they must be implemented by the compiler. This is also the only way 
to implement exceptions in both a safe and efficient way. I'm sorry, 
but hacking exceptions in on the library level as an after-thought 
doesn't make sense. Then its more honest to just not implement them at 
all.


Regards,

Dietmar Planitzer