199
>>>> 9 UIFoundation0x7fff23c3c697 -[NSRTFReader
>>>> defaultParagraphStyle] + 75
>>>> 10 UIFoundation0x7fff23c3c5be -[NSRTFReader
>>>> _mutableParagraphStyle] + 112
>>>> 11 U
] + 76
>>> 13 UIFoundation 0x7fff23c311a6
>>> _NSReadAttributedStringFromURLOrData + 3213
>>> 14 UIFoundation0x7fff23d46985
>>> -[NSAttributedString(NSAttributedStringUIFoundationAdditions)
>>> ini
backtrace be nil...and more interestingly,
>> why is the exception not being caught?
>>
>> Thanks
>> Mark
>> ___
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin
ng(NSAttributedStringUIFoundationAdditions)
> > initWithURL:options:documentAttributes:error:] + 228
> > 15 AppKit 0x7fff23677d9a -[NSTextView
> > readRTFDFromFile:] + 126
> > 16 MyAppHere 0x000105fa18a7 MyAppHere+
ttributes:error:] + 228
>> 15 AppKit 0x7fff23677d9a -[NSTextView
>> readRTFDFromFile:] + 126
>> 16 MyAppHere 0x000105fa18a7 MyAppHere+
>> 227495
>> 17 AppKit 0x7fff230af
gt;>> _NSReadAttributedStringFromURLOrData + 3213
>>> 14 UIFoundation 0x7fff23d46985
>>> -[NSAttributedString(NSAttributedStringUIFoundationAdditions)
>>> initWithURL:options:documentAttributes:error:] + 228
>>> 15 AppKit
tions)
>> initWithURL:options:documentAttributes:error:] + 228
>> 15 AppKit 0x7fff23677d9a -[NSTextView
>> readRTFDFromFile:] + 126
>> 16 MyAppHere 0x000105fa18a7 MyAppHere+
>> 227495
>> 17 AppKi
MyAppHere 0x000105fa18a7 MyAppHere+ 227495
> 17 AppKit 0x7fff230af7fd
> -[NSApplication(NSResponder) sendAction:to:from:] + 283
> 18 AppKit 0x7fff231b2611 -[NSMenuItem
> _corePerform
On Tue, Mar 22, 2011 at 8:07 AM, A.M. wrote:
> I am curious as to how you would propose to add error: handlers to DO calls
> considering that DO is meant to transparent and cannot modify method
> signatures. For example, assuming you were designing a new DO framework, how
> would you propose ch
On Mar 21, 2011, at 10:24 PM, Chris Hanson wrote:
> Ultimately, the solution will be to modify HessianKit -- or any other
> framework that presents an RPC-style interface[1] -- to follow the Cocoa
> convention of returning BOOL (or a non-nil/nil object reference) to indicate
> success or failu
On Mar 21, 2011, at 7:24 PM, Chris Hanson wrote:
> The reason is that if your exception crosses any stack frame you don’t fully
> control, all bets are off when it comes to the state of your program. The
> frameworks have all been written with the assumption that exceptions are only
> for cat
On Mar 21, 2011, at 2:19 PM, Rick Mann wrote:
>> You can't currently throw an exception across a forwarded call. When the
>> exception unwinder hits the forwarding frame, it stops and the exception
>> goes uncaught. You'll need to put your exception handler at a different
>> level.
>
> Hrm. Th
Hi Johnathan
On 21/03/11, Rick Mann & Jonathan Mitchell wrote:
My NSOperation subclass wraps the call to the network code in a
@try/catch block. But when this exception is raised, the app
terminates due to an uncaught exception.
Exceptions on the main thread of a Cocoa application do not typ
On Mar 21, 2011, at 2:43 PM, Laurent Daudelin wrote:
> On Mar 21, 2011, at 14:19, Greg Parker wrote:
>> (The problem is that the forwarding machinery is hand-written assembly, and
>> nobody added hand-written exception unwind tables to match. With "zero-cost"
>> exceptions, the unwinder cannot pr
On Mar 21, 2011, at 14:19, Greg Parker wrote:
> (The problem is that the forwarding machinery is hand-written assembly, and
> nobody added hand-written exception unwind tables to match. With "zero-cost"
> exceptions, the unwinder cannot process a frame without its unwind tables.)
Hand-written a
On Mar 21, 2011, at 2:19 PM, Greg Parker wrote:
> On Mar 21, 2011, at 2:06 PM, Kyle Sluder wrote:
>> On Mon, Mar 21, 2011 at 2:03 PM, Greg Parker wrote:
>>> You can't currently throw an exception across a forwarded call. When the
>>> exception unwinder hits the forwarding frame, it stops and th
On Mar 21, 2011, at 2:03 PM, Greg Parker wrote:
> On Mar 20, 2011, at 9:11 PM, Rick Mann wrote:
>> On Mar 20, 2011, at 12:45 PM, jonat...@mugginsoft.com wrote:
>>> On 20 Mar 2011, at 19:17, Rick Mann wrote:
I have some code, called from a subclass of NSOperation, that throws an
excepti
On Mar 21, 2011, at 2:06 PM, Kyle Sluder wrote:
> On Mon, Mar 21, 2011 at 2:03 PM, Greg Parker wrote:
>> You can't currently throw an exception across a forwarded call. When the
>> exception unwinder hits the forwarding frame, it stops and the exception
>> goes uncaught. You'll need to put your
On Mon, Mar 21, 2011 at 2:03 PM, Greg Parker wrote:
> You can't currently throw an exception across a forwarded call. When the
> exception unwinder hits the forwarding frame, it stops and the exception goes
> uncaught. You'll need to put your exception handler at a different level.
Does this li
On Mar 21, 2011, at 2:03 PM, Greg Parker wrote:
> On Mar 20, 2011, at 9:11 PM, Rick Mann wrote:
>> On Mar 20, 2011, at 12:45 PM, jonat...@mugginsoft.com wrote:
>>> On 20 Mar 2011, at 19:17, Rick Mann wrote:
I have some code, called from a subclass of NSOperation, that throws an
excepti
On Mar 20, 2011, at 9:11 PM, Rick Mann wrote:
> On Mar 20, 2011, at 12:45 PM, jonat...@mugginsoft.com wrote:
>> On 20 Mar 2011, at 19:17, Rick Mann wrote:
>>> I have some code, called from a subclass of NSOperation, that throws an
>>> exception pretty reliably if I put a breakpoint elsewhere in th
On Mar 21, 2011, at 2:50 AM, jonat...@mugginsoft.com wrote:
> As you are raising the exception then you could try raising the exception
> experimentally when the operation starts to help source the problem.
> You mentioned break points earlier. What happens when the code runs outside
> of the d
On 21 Mar 2011, at 04:11, Rick Mann wrote:
>> Can you give us the exception report?
>> Is it an NSException instance?
>
> Yes. It is raised by this line of code:
>
>[NSException raise:NSInvalidArchiveOperationException format:@"Network
> error domain:%@ code:%d", [requestError domain], [re
On Mar 20, 2011, at 12:45 PM, jonat...@mugginsoft.com wrote:
>
>
> On 20 Mar 2011, at 19:17, Rick Mann wrote:
>
>> I have some code, called from a subclass of NSOperation, that throws an
>> exception pretty reliably if I put a breakpoint elsewhere in the code (it is
>> code that does an HTTP
On 20 Mar 2011, at 19:17, Rick Mann wrote:
> I have some code, called from a subclass of NSOperation, that throws an
> exception pretty reliably if I put a breakpoint elsewhere in the code (it is
> code that does an HTTP request, and it's getting a broken pipe, and raising
> an exception to r
I have some code, called from a subclass of NSOperation, that throws an
exception pretty reliably if I put a breakpoint elsewhere in the code (it is
code that does an HTTP request, and it's getting a broken pipe, and raising an
exception to report it; the breakpoint (in another thread) seems to
26 matches
Mail list logo
