Exceptions in Objective-C

Exceptions in Objective-C

Post by Christian Brunsch » Fri, 27 Jun 2003 03:08:56



This might interest people.

Apple have released an update to their developer tools, including a new
compiler based on GCC 3.3 - and the release notes include a little
surprise:

<quote>

New language features

ObjC/ObjC++ exception and synchronization support

The Objective-C language now offers syntactic support for structured
exception handling that is similar to what is offered by C++ and Java.  To
enable the new syntax, you must pass the '-fobjc-exceptions' options to
the ObjC/ObjC++ compiler, and/or set the MACOSX_DEPLOYMENT_TARGET
environment variable to "10.3".


       ...

       ...
    }

       ...

       ...

       ...
     }

       ...
      }

       ...
     }

       ...
     }




rethrown.

Note that only (pointers to) Objective-C objects may be thrown and caught
using this scheme.  When an object is thrown, it will be caught by the


be provided to catch any and all Objective-C exceptions not caught by




There are several caveats to using the new exception mechanism:

* Although currently designed to be binary compatible with
  NS_HANDLER-style idioms provided by the NSException class, the new
  exceptions can only be used on Mac OS X 10.3 (Panther) and later
  systems, due to additional functionality needed in the Objective-C
  runtime.

* As mentioned above, the new exceptions do not support handling types
  other than Objective-C objects. The Objective-C exception model does
  not interoperate with C++  exceptions at this time.  This means you
  cannot throw an exception from Objective-C and catch it from C++, or
  vice versa.

The '-fobjc-exceptions' switch also enables the use of synchronization
blocks for thread-safe execution:


        ...
   }

</quote>

Anyone who is familiar with Java's exception handling model will
immediately recognize it here; though there is the distinction that the
objects that can be thrown appear to be arbitrary Objective-C objects, and
not limited to any particular 'Throwable' class hierarchy as they are in
Java.

The familiar Java exception handling keywords are being used, but with the

Likewise, the ability to declare a block as being synchronized on a lock
object to ensure thread-safe execution, also seems to be copied right from
Java.

[ Personal comments:

Hmm.

I'm slightly in two minds about this. It's nice that Objective-C has
finally got actual proper exception handling - the Cocoa
NS_DUring/NS_HANDLER/NS_ENDHANDLER macros were, while functional, not an
ideal solution to the problem - and certainly using an exception model,
including syntax, that will be familiar to many developers, is also a very
reasonable decision. But at the same time, I'm not sure how well this
meshes with the rest of Objective-C. Maybe this is just the usual
immediate wary reaction to something that is new and changes somehing that
one's gotten attached to; I'll see how I feel about it once I've started
to use it a bit more.

]

Best wishes,

// Christian Brunschen

 
 
 

Exceptions in Objective-C

Post by Michael As » Fri, 27 Jun 2003 04:27:06




Quote:> Hmm.

> I'm slightly in two minds about this. It's nice that Objective-C has
> finally got actual proper exception handling - the Cocoa
> NS_DUring/NS_HANDLER/NS_ENDHANDLER macros were, while functional, not an
> ideal solution to the problem - and certainly using an exception model,
> including syntax, that will be familiar to many developers, is also a very
> reasonable decision. But at the same time, I'm not sure how well this
> meshes with the rest of Objective-C. Maybe this is just the usual
> immediate wary reaction to something that is new and changes somehing that
> one's gotten attached to; I'll see how I feel about it once I've started
> to use it a bit more.

Error handling in Cocoa fairly sucks, mostly because it's inconsistent.
Sometimes it juts returns nil, sometimes it's some other return value
that signifies an error, sometimes there's a method you call to see if
an error happened, and sometimes it throws an exception. Exceptions seem
under-used in Cocoa, and maybe this will help change that.


reference counting goes. No more putting everything into autorelease
pools, you can put releases in your finally blocks.

I'm curious as to how much overhead there is for this. IIRC, enabling
C++ exceptions used to generate a significant amount of overhead in the
program, although I understand it's better now.

There's an odd statement in this note:

Quote:> * Although currently designed to be binary compatible with
>   NS_HANDLER-style idioms provided by the NSException class, the new
>   exceptions can only be used on Mac OS X 10.3 (Panther) and later
>   systems, due to additional functionality needed in the Objective-C
>   runtime.

I can't figure out what it means; why is it binary-compatible if you
need 10.3 anyway? Does this just mean that you can mix the old style and
new style exceptions? Is this so that you can use the new syntax even if
you use old libraries in your program?

Another concern is Objective-C++. It says you can't mix the exceptions,
but it doesn't say anything about its interactions with C++ objects,
specifically destructors. The old NSException stuff can't mix with C++
objects on the stack without a bunch of extra work.

My general impression is that it's not really necessary. ObjC's entire
principle is a lightweight syntax layer on top of C. But I don't see it
as being too harmful, especially since people seem to avoid doing
anything with exceptions simply because they're so bizarre to use. One
thing I am sure of, these extensions will be the subject of at least one
flamewar in this group.

 
 
 

Exceptions in Objective-C

Post by Luc Heinri » Sat, 28 Jun 2003 01:39:08



> One
> thing I am sure of, these extensions will be the subject of at least one
> flamewar in this group.

This sounds pretty optimistic to me... :)

--

 
 
 

Exceptions in Objective-C

Post by Greg Parke » Sat, 28 Jun 2003 04:36:57



> I'm curious as to how much overhead there is for this. IIRC, enabling
> C++ exceptions used to generate a significant amount of overhead in the
> program, although I understand it's better now.


(C++ try blocks are free if you don't throw, although they do increase
the size of the binary.)

Quote:> There's an odd statement in this note:

> > * Although currently designed to be binary compatible with
> >   NS_HANDLER-style idioms provided by the NSException class, the new
> >   exceptions can only be used on Mac OS X 10.3 (Panther) and later
> >   systems, due to additional functionality needed in the Objective-C
> >   runtime.

> I can't figure out what it means; why is it binary-compatible if you
> need 10.3 anyway? Does this just mean that you can mix the old style and
> new style exceptions? Is this so that you can use the new syntax even if
> you use old libraries in your program?




require extra functions in the runtime that are only available in 10.3.

> Another concern is Objective-C++. It says you can't mix the exceptions,
> but it doesn't say anything about its interactions with C++ objects,
> specifically destructors. The old NSException stuff can't mix with C++
> objects on the stack without a bunch of extra work.


Integrating with C++ exceptions and destructors is hard, and we haven't
worked out a reasonable way to mix them yet.

--

 
 
 

Exceptions in Objective-C

Post by Christian Brunsch » Sat, 28 Jun 2003 17:47:36





>> I'm curious as to how much overhead there is for this. IIRC, enabling
>> C++ exceptions used to generate a significant amount of overhead in the
>> program, although I understand it's better now.


>(C++ try blocks are free if you don't throw, although they do increase
>the size of the binary.)

There'salways _some_ cost associated with everything.

One thing I just want to check: In Java, a finally block is executed after
exiting from one of its associated try or catch blocks, regardless of how
- including by way of a return; does this hold here as well? (I'd expect
it to, but assumptions are always dangerous.)




>require extra functions in the runtime that are only available in 10.3.

... which explains why I got 'undefined symbols' after trying to check it
out on 10.2.6 with the updated gcc.


>Integrating with C++ exceptions and destructors is hard, and we haven't
>worked out a reasonable way to mix them yet.

That does sound like a hairy problem :(

Best wishes,

// Christian Brunschen

 
 
 

Exceptions in Objective-C

Post by Mr. Mago » Wed, 02 Jul 2003 13:04:51




> > I can't figure out what it means; why is it binary-compatible if you
> > need 10.3 anyway? Does this just mean that you can mix the old style and
> > new style exceptions? Is this so that you can use the new syntax even if
> > you use old libraries in your program?




> require extra functions in the runtime that are only available in 10.3.

Greg,

In the old days (ok, today :-) I'd write


raise];

What does that translate into in the new days?

nil];

???

Thanks,
M.