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
14 matches
Mail list logo
