Re: Where and how do I know a save completed successfully?
Re: Where and how do I know a save completed successfully?
- Subject: Re: Where and how do I know a save completed successfully?
- From: Michael Crawford <email@hidden>
- Date: Wed, 29 Apr 2015 11:15:21 -0700
> 1. The compiler crash should never happen, obviously, so that's a bug report.
To be more clear - it doesn't matter how screwed up your source could
possibly be, the compiler must never crash. If it does, then it's a
bug in the compiler.
It's quite likely that a slightly more subtle problem in your source
would result in incorrect machine code generation. I've actually seen
that happen. In my case I knew I was getting bad machine code;
increasing the number of characters in certain symbol names lead to
the MPW C compiler setting my Mac up the bomb.
Michael David Crawford, Consulting Software Engineer
email@hidden
http://www.warplife.com/mdc/
Available for Software Development in the Portland, Oregon Metropolitan
Area.
On Wed, Apr 29, 2015 at 10:22 AM, Quincey Morris
<email@hidden> wrote:
> On Apr 29, 2015, at 02:08 , Charles Jenkins <email@hidden> wrote:
>>
>> override func saveToURL(
>> url:NSURL,
>> ofType typeName:String,
>> forSaveOperation saveOperation:
>> NSSaveOperationType,
>> completionHandler:(NSError!) -> Void
>> ) {
>> // <snip> Here I prepare my data structures for saving
>>
>> //super.saveToURL( url, ofType:typeName, forSaveOperation:saveOperation, completionHandler:completionHandler )
>>
>> super.saveToURL(
>> url,
>> ofType:typeName,
>> forSaveOperation:saveOperation,
>> completionHandler:{
>> ( error:NSError! ) -> Void in {
>> completionHandler( error )
>> // TODO: If no error, mark data structures as "clean"
>> }
>> }
>> )
>> }
>
> 1. The compiler crash should never happen, obviously, so that's a bug report.
>
> 2. The bridged protocol method is apparently wrong. Since the error parameter is explicitly documented as being nil on success, it should be NSError?. (Note that it's possible at runtime for an implicitly unwrapped optional (!) to be nil, and you can test for it being nil, but we saw in your previous adventure that an app will crash if the Swift runtime tries to enter a Swift method with a nil value for an implicitly unwrapped optional, at least when coming from the Obj-C runtime).
>
> 3. The bridged method signature isn't syntactically correct, though it isn't exactly wrong either. There's no need for parentheses in '(NSError!)'. A 1-tuple is by definition the same thing as the element in the tuple, but I wouldn't be surprised if the compiler doesn't handle this in all cases.
>
> 4. Similarly, the parentheses in your super invocation aren't necessary, nor is the default return type (... '( error:NSError! ) -> Void in' ...).
>
> 5. It's not necessary to open an new brace after 'in', though this shouldn't be wrong either.
>
> So, that's a lot of slightly unusual stuff, and the crash could be caused by any one of them. In Xcode 6.3.1, the following compiles for me without errors, warnings or a compiler crash:
>
> override func saveToURL(url: NSURL, ofType typeName: String, forSaveOperation saveOperation: NSSaveOperationType, completionHandler: NSError? -> Void) {
> super.saveToURL(url, ofType: typeName, forSaveOperation: saveOperation) {error in /*...*/ return}
> }
>
> See if that works for you. (But don't forget your bug report!)
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden