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
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
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: Thursday, June 14,
asey 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
2018, at 18:00
> 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
>
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
> 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
> 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
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.
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
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
On Thursday, June 10, 2010, Kyle Sluder kyle.slu...@gmail.com wrote:
On Thu, Jun 10, 2010 at 1:58 PM, Frederick C.Lee
frederick_...@apple.com 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
On Thu, Jun 10, 2010 at 1:58 PM, Frederick C.Lee
frederick_...@apple.com 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
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
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
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 to programming errors; you should
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 64-bit runtime
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 following code is sufficient enough
for the IPC exception handling?
Instead of having to manually write @try/@catch wherever I doing
, 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
exceptions.
This wrapper class is simply an NSObject, and will call
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 -
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
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 methods
methodSignatureForSelector, and forwardInvocation when I try
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 Leel...@thaesofereode.info wrote:
On Sep 7, 2009, at 20:02 , Edward Chan wrote:
Hello,
I'm using KVO on a Distributed Object, and I
Also,
Did they explain why they didn't want to support it?
Thanks,
Ed
On Mon, Sep 7, 2009 at 4:45 PM, Edward Chanedch...@gmail.com 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
)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 following code is sufficient enough
for the IPC exception handling?
Instead
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
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
incomplete. The problem
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's just like exception handling in
any other language.
--Kyle Sluder
___
Cocoa-dev
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 very different sort of exception handling. Hardware
exception
33 matches
Mail list logo
