Re: [Pyobjc-dev] exception handling design pattern

[Bill B. <bb...@co...>]

On Wednesday, October 16, 2002, at 03:31 PM, Ronald Oussoren wrote:
> On Wednesday, Oct 16, 2002, at 16:27 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> On Wednesday, October 16, 2002, at 02:42 AM, Ronald Oussoren wrote:
>>> On Tuesday, Oct 15, 2002, at 23:53 Europe/Amsterdam, Bill Bumgarner 
>>> wrote:
>>>> Looking at the implementation, it looks like the problem lies in 
>>>> the behavior of the ObjC->Python part of the bridge in that it 
>>>> leaves the NSException in a wrapped up state?
>>> That's right. I never got around to implement this, adding this code 
>>> should be relatively straightforward. I'll look into it.
>>
>> Thanks.   It isn't a huge issue, but anything that makes the bridge 
>> more transparent is definitely a boon.
> I've just checked in a fix. Forwarding exceptions in the 'other' 
> runtime is now cleaner, and when the exception travels back into its 
> own runtime it regains its original identity.

Excellent!!

> There is one thing I have not really looked into yet: What is the 
> normal way of processing exceptions in Objective-C, do you use '==' or 
> 'isEqual' to check if the exception is one you can handle? If it is 
> the former some additional work is necessary: NSString objects are 
> transparently translated into Python strings and Python strings are 
> translated in (freshly allocated) NSStrings. Thus when you trow 
> NSSomeException from Python it is 'isEqual' on the Objective-C side 
> but not '=='.

It is generally done via isEqualToString: on the -name and, as such, 
shouldn't be a problem in properly written code.

>
>> BTW:  The bridge is working *really* well.  I'm using it in a 
>> production development setting and have had 0 problems other than of 
>> my own making (the exception issue wasn't a big deal).
> Wow, I can debug without a real testsuite :-)

Speaking of:  I would eventually like to toss together a python-esque 
test suite for PyObjC that is included with the distribution.

In the case of exceptions, I simply switched to using:

     raise NSInternalInconsistencyException, "Something really, really 
bad happened."

Other than the lack of a userInfo dictionary into which I occasionally 
carry along some meta info, this works fine.  Now that I can toss 
proper Obj-C exceptions, this limitation can go away, as well.

Though -- thinking it through -- likely continuing with the raise style 
pure-python exception is the way to go if the bridge converts it 
correctly.  I just wish there was a way to carry along meta info.

>>> BTW. I've been playing with libffi and I'm pretty sure it can be 
>>> used to remove the need for the register.m file. I already have a 
>>> function that returns an 'IMP' for in the Objective-C method 
>>> dispatch table (given a method signature). I can't test this at the 
>>> moment because libffi refused to build into a shared library...
>>
>> If the inclusion of a shared library requires end users of standalone 
>> applications to go through some kind of installation process to have 
>> the shlib dumped off in the proper location, I will be very strongly 
>> against the inclusion of features that require a shared library.
>
> I agree, if I get this into a usable shape libffi should be linked 
> into the objc._objc module (no seperate shared library). An external 
> library should also never be required for using PyObjC, we should keep 
> the current mechanism.

Definitely on the same page there!  Good!

> The problem I'm currently having is that one of the source files won't 
> compile into an object file that can be used in a dynamicly loaded 
> object.

What is the problem?  I have tangled with these issues in the past.

b.bum