BTW, raising an NSException inside a C++
try{}
catch(...){}
block also seems to work OK. It does get caught.
Casey McDermott
On Sat, 6/16/18, Alastair Houghton wrote:
Subject: Re: Exception handling
To: "Jens Alfke"
Cc: "
On 15 Jun 2018, at 19:30, Jens Alfke wrote:
>
>> On Jun 14, 2018, at 5:58 PM, Quincey Morris
>> wrote:
>>
>> as someone already mentioned, NSExceptions can’t successfully cross
>> dylib/framework boundaries.
>
> They can, actually; there is no problem with this at the ABI/runtime level.
>
>
Along those lines, here are some approaches we used on iOS to catch exceptions
and to throw exceptions.
- (id)argument {
if (!_argument) {
@throw [NSException exceptionWithName:NSInternalInconsistencyException
reason:@"Argument requested has yet to be captured." userInfo:nil];
> On Jun 14, 2018, at 5:58 PM, Quincey Morris
> wrote:
>
> as someone already mentioned, NSExceptions can’t successfully cross
> dylib/framework boundaries.
They can, actually; there is no problem with this at the ABI/runtime level.
I think what you mean is that most libraries/frameworks do
On Jun 14, 2018, at 11:33 , Casey McDermott wrote:
>
> However, simply replacing the C++ throw with a Cocoa exception via
> [NSException raise : errString format : errString]; seems to work great.
> Apparently it unwinds the call stack and is swallowed in the run loop.
Yes, but do be careful
> On Jun 14, 2018, at 11:33 AM, Casey McDermott wrote:
>
> However, simply replacing the C++ throw with a Cocoa exception via
> [NSException raise : errString format : errString]; seems to work great.
Yeah, I think that’s because the exception type being thrown is now
NSException* instead of
ugs.
>
> Thanks for all the help,
>
> Casey McDermott
>
> ----
> On Thu, 6/14/18, Alastair Houghton wrote:
>
> Subject: Re: Exception handling
> To: "Jens Alfke"
> Cc: "Casey McDermott" , "cocoa-dev list"
>
> Date: Thur
ll the help,
Casey McDermott
On Thu, 6/14/18, Alastair Houghton wrote:
Subject: Re: Exception handling
To: "Jens Alfke"
Cc: "Casey McDermott" , "cocoa-dev list"
Date: Thursday, June 14, 2018, 1:11 PM
On 14 Jun
> On Jun 14, 2018, at 10:11 AM, Alastair Houghton
> wrote:
>
> I don’t think it’s changed in any obvious way; the framework has always
> swallowed exceptions in certain contexts, but not in others. Obviously the
> precise detail may have changed over time, but it’s certainly crashed on
> ex
On 14 Jun 2018, at 18:00, Jens Alfke wrote:
>
>> On Jun 13, 2018, at 7:22 PM, Casey McDermott wrote:
>>
>> Our Carbon event loop had a try/catch block, which caught most exceptions,
>> and then
>> continued. It started as an expedient in early production, but it remained
>> in production cod
> On Jun 13, 2018, at 7:53 PM, Quincey Morris
> wrote:
>
> The situation with C++ exceptions is a bit different.
It's actually exactly the same, since at the runtime level Obj-C exceptions are
C++ exceptions.
> I really think you have exactly 2 error handling patterns:
> 1. Returning false
> On Jun 13, 2018, at 7:22 PM, Casey McDermott wrote:
>
> Our Carbon event loop had a try/catch block, which caught most exceptions,
> and then
> continued. It started as an expedient in early production, but it remained
> in production code
> since it often allows users to continue, save t
On 14 Jun 2018, at 03:53, Quincey Morris
wrote:
>
> On Jun 13, 2018, at 19:22 , Casey McDermott wrote:
>>
>> Nearly always, the event loop is the best place to escape to.
>
> This is not how current thinking goes, unless you mean something different
> from what I think you’re saying.
Agreed
On Jun 13, 2018, at 19:22 , Casey McDermott wrote:
>
> Nearly always, the event loop is the best place to escape to.
This is not how current thinking goes, unless you mean something different from
what I think you’re saying.
If you’re implementing sanity (“should not happen”) checks, then the
We are updating a large Carbon accounting app to Cocoa. There is a ton of
C++ model-layer code. It originally was based on PowerPlant, but the new
interface is Objective-C
with many bridges to the C++.
Our Carbon event loop had a try/catch block, which caught most exceptions, and
then
continue
On Jun 10, 2010, at 1:58 PM, Frederick C.Lee wrote:
> Is it acceptable to merely trap for the out-of-bound exception within the
> method() and continue my way?
> ... or should I test EVERY TIME I access a member, to see if the member exist?
For better or worse, Cocoa’s policy policy is that an
Greetings:
I have a situation where I need to access a member of a mutable array (max
4 members).
Sometimes I could get an out-of-bounds exception, if for example, I try to
access member #3 out of a 2-member array.
It's not serious, I could just ignore it and continue.
Question:
Is it acc
On Thu, Jun 10, 2010 at 1:58 PM, Frederick C.Lee
wrote:
> Greetings:
> I have a situation where I need to access a member of a mutable array (max
> 4 members).
> Sometimes I could get an out-of-bounds exception, if for example, I try to
> access member #3 out of a 2-member array.
> It's not s
On Thursday, June 10, 2010, Kyle Sluder wrote:
> On Thu, Jun 10, 2010 at 1:58 PM, Frederick C.Lee
> wrote:
>> Greetings:
>> I have a situation where I need to access a member of a mutable array
>> (max 4 members).
>> Sometimes I could get an out-of-bounds exception, if for example, I try to
On Nov 28, 2009, at 1:29 PM, Helen Cooper wrote:
> "exceptions are resource-intensive in Objective-C"
In the 32-bit runtime, @try is fairly expensive (it has to save all the CPU
registers to the stack), so you pay for exception handling even if no
exceptions are thrown.
In the 6
I'm trying to understand when to use exception handling when developing Cocoa
applications. In regard to this, two points stand out to me in Apple's
documentation:
"exceptions are resource-intensive in Objective-C"
"Conditions giving rise to exceptions are due t
On Sep 7, 2009, at 21:45 , Edward Chan wrote:
Great...
How long ago did you ask the Apple engineers? I haven't tried this
piece of code with Snow Leopard actually...
This was back in February, I was probably testing on Leopard. The
difference between what you and I tried was that I used -
b
On Sep 7, 2009, at 20:02 , Edward Chan wrote:
Hello,
I'm using KVO on a Distributed Object, and I am binding my UI controls
based on the observer.
Hi,
not much of constructive help from me I'm afraid, just a warning. I
also did the same thing once, and the reaction from Apple engineers
w
some hassles of sending
NSNotifications and
such.
So, what I'm wondering is if the following code is sufficient enough
for the IPC exception handling?
Instead of having to manually write @try/@catch wherever I doing
some
IPC, I create a wrapper object around the DO to handle the
exce
>> }
>>
>> - (void)setIsEatingABanana:(BOOL)flag
>> {
>> [MonkeyBrainDOObject setBanana:flag];
>> isEatingABanana = flag;
>> }
>>
>>
>> This indeed works, and we save some hassles of sending NSNotifications and
>> su
On Sep 7, 2009, at 4:45 PM, Edward Chan wrote:
Great...
How long ago did you ask the Apple engineers? I haven't tried this
piece of code with Snow Leopard actually...
It still isn't supported in SL. I'd be shocked if it ever is.
___
Cocoa-dev m
[self didChangeValueForKey:@"isEatingABanana"];
}
}
- (void)setIsEatingABanana:(BOOL)flag
{
[MonkeyBrainDOObject setBanana:flag];
isEatingABanana = flag;
}
This indeed works, and we save some hassles of sending
NSNotifications and such.
So, what I'm wondering is if the fol
Also,
Did they explain why they didn't want to support it?
Thanks,
Ed
On Mon, Sep 7, 2009 at 4:45 PM, Edward Chan wrote:
> Great...
>
> How long ago did you ask the Apple engineers? I haven't tried this
> piece of code with Snow Leopard actually...
>
>
> On Mon, Sep 7, 2009 at 3:29 PM, Graham Le
Great...
How long ago did you ask the Apple engineers? I haven't tried this
piece of code with Snow Leopard actually...
On Mon, Sep 7, 2009 at 3:29 PM, Graham Lee wrote:
> On Sep 7, 2009, at 20:02 , Edward Chan wrote:
>
>> Hello,
>>
>> I'm using KVO on a Distributed Object, and I am binding my U
27;m wondering is if the following code is sufficient enough
for the IPC exception handling?
Instead of having to manually write @try/@catch wherever I doing some
IPC, I create a wrapper object around the DO to handle the exceptions.
This wrapper class is simply an NSObject, and will call the meth
r is a subclass of the type of the
pointer provided in the @catch directive, then that @catch block will
be executed. The first one to match wins.
> I do have some experience with exception handling, but Objective-C's has
> very few parallels with that of mainframe assembler.
This is a
gram dies.
If a @catch block somewhere executes, then all the @finally blocks
that should execute are executed in the order of the stack's
unwinding, and then control resumes after the @try/@catch/@finally
block that caught the exception. It'
I'm not clear about the semantics of the Objective-C exception-
handling constructs, even after going through the Apple Objective-C
documentation and the developer-doc conceptual "Exception Handling".
The definitions are very terse or missing and the examples are
incomple
OK, so:
[[NSExceptionHandler defaultExceptionHandler]setDelegate:self];
[[NSExceptionHandler defaultExceptionHandler]setExceptionHandlingMask:
0
| NSHandleUncaughtExceptionMask
| NSHandleUncaughtSystemExceptionMask
|
34 matches
Mail list logo
