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 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 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 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 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
Thanks, this is all useful info. I checked NSExceptionHandler and
NSUncaughtExceptionHandler, but they are just for logging before termination.
NSRunLoop is accessible but there's not much there.
However, simply replacing the C++ throw with a Cocoa exception via
[NSException raise : errString fo
The hockeyApp framework has a lot explanation about this:
https://www.hockeyapp.net/help/sdk/mac/4.0.2/Classes/BITCrashExceptionApplication.html
Best
Georg Seifert
> Am 14.06.2018 um 14:33 schrieb Casey McDermott :
>
> Thanks, this is all useful info. I checked NSExceptionHandler and
> NSUnca
> 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
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
