 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Perl / August 2004Odd Camelbones bug
Here is an odd problem i found. $self->{'textBoxen'}->setString($file); if file is undefined, the app blows up real good. 2004-08-06 15:06:38.993 PerlButtonTest[3392] An uncaught exception was raised 2004-08-06 15:06:38.993 PerlButtonTest[3392] *** -[NSTextView replaceCharactersInRange:withString:]: nil NSString given. 2004-08-06 15:06:38.993 PerlButtonTest[3392] *** Uncaught exception: <NSInvalidArgumentException> *** -[NSTextView replaceCharactersInRange:withString:]: nil NSString given. PerlButtonTest has exited due to signal 5 (SIGTRAP). Hi, > Here is an odd problem i found. > [quoted text clipped - 11 lines] > > PerlButtonTest has exited due to signal 5 (SIGTRAP). the way I understand things, this is more a Cocoa problem then a Camelbones problem. Camelbones just passes arguments through to the Objective-C function, and if "setString" does not like null strings, there is little CB can do about it. You will have to do argument checking by yourself to make sure things work. Something like $self->{'textBoxen'}->setString(defined $file ? $file :: ''); What would be nice, though, is if CB could somehow suppress the SIGTRAP and wrap it into a normal Perl exception, that we could catch with an eval-block. Anyone knows how to do that? Thilo > What would be nice, though, is if CB could somehow suppress the > SIGTRAP and wrap it into a normal Perl exception, that we could catch > with an eval-block. > > Anyone knows how to do that? I do. ;-) What you've described is exactly the plan, to wrap the call to the ObjC method in the normal exception macros for ObjC. If an exception is caught, it would be passed to the XS equivalent to the die() function. I need to do some work on exception handling in the other direction, too, so that an NSException that's fired from Perl is handled, unwinding the Perl call stack to a sane state before propagating the exception. sherm-- > the way I understand things, this is more a Cocoa problem then a > Camelbones problem. > Camelbones just passes arguments through to the Objective-C function, > and if "setString" does not like null strings, there is little CB can > do about it. Exactly. An undef value is simply passed as nil to ObjC, and some methods can handle that. To some methods, that's actually a meaningful value - for example, passing undef to NSResponder's setTarget() method tells it to send action methods to the responder chain instead of to a single hard-coded target object. Methods bridged to Perl aren't written by hand; they're automagically generated by querying the ObjC runtime as to the types of the arguments and return value. The ObjC runtime can't tell whether nil is acceptable or not, because that's not declared as part of a method definition in ObjC. So, we're left with what Thilo suggested - check for undef before calling a method that can't handle it. sherm-- |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.