Cheers for the clarification. I started assuming there may be a reason when changing the guard let on the launch args to use the InvalidArgumentException.
Could this be a position where we may need os checking to cover the regression for the moment. It seems odd that the test would pass in CI when an error is thrown with a try! but fail on OSX Sent from my iPhone > On 13 May 2016, at 20:48, Tony Parker <anthony.par...@apple.com> wrote: > > Hi James, > >> On May 13, 2016, at 12:25 PM, James Lee via swift-corelibs-dev >> <swift-corelibs-dev@swift.org> wrote: >> >> Following on from a previous discussion with Tests failing on OSX. I have >> been looking into the failures. It seems that one of the earliest failures >> is due to an error from a try! within NSTask.launch(). This came in with >> this commit: >> https://github.com/apple/swift-corelibs-foundation/commit/4c6f04cfcad3d4b06688558021595d06751fc66a >> >> Going by the docs for Foundation - The launch function apparently "Raises an >> NSInvalidArgumentException if the launch path has not been set or is invalid >> or if it fails to create a process." >> >> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSTask_Class/#//apple_ref/occ/instm/NSTask/launch >> >> My question is, should this be built into the Swift Foundation API? The >> documentation for Swift doesn't state that the launch function throws. >> >> With the test that is failing expecting an error, it feels more Swift-y to >> have any errors throw explicitly, rather than looking at what the lower >> level fills the data with. >> >> But before jumping into doing this, I would rather put it out there and see >> what the community feels about this? > > Unfortunately the ‘throws’ syntax in Swift often causes a mixup between two > different things, because it flipped the terminology from what all of our > documentation and header comments use. > > 1. Cocoa uses exceptions (@throw in ObjC) to indicate programmer errors and > they are generally not intended to be recoverable. Example: passing nil > where not expected, passing an invalid argument, failing to meet a > precondition of an API. > 2. Cocoa uses NSError ** to indicate runtime errors that are recoverable or > at least presentable to user. Example: out of disk space, name of file > already exists. > > The ‘throws’ syntax in Swift is actually for case #2, not #1. In Swift, #1 is > fatalError or preconditionFailure. #2 is ‘throw Error’. > > In the case of NSTask, when the documentation says “raises an > NSInvalidArgumentException” (#1) then in Swift, that should translate to > fatalError or preconditionFailure. > > Hope this helps, > - Tony > >> Cheers >> >> James >> _______________________________________________ >> swift-corelibs-dev mailing list >> swift-corelibs-dev@swift.org >> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > _______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
