[swift-evolution] Pitch: Replacement for Process

Charles Srstka cocoadev at charlessoft.com
Tue Feb 14 09:37:15 CST 2017


MOTIVATION:

In Swift 3, NSTask was renamed to Process, making it the de facto API for spawning external tasks in Swift applications. Unfortunately, NSTask uses Objective-C exceptions to report runtime errors in spawning external tasks, which cannot be caught from Swift code. This means that if something goes wrong, like the file unexpectedly not existing at the launch path, or the current user not having permission to launch it or something, there’s no way to handle that gracefully other than crashing the whole program.

PROPOSED SOLUTION:

Rename Process back to NSTask, and provide a Swift-native Process class for Foundation in Swift 4 that mimics NSTask's interface, but provides a throwing version of the ‘launch’ method:

open class Process {
    // ...
    
    open func launch() throws

    // ...
}

Almost all of the work for this is already done in the swift-corelibs-Foundation project. The only NSUnimplemented() calls are in the suspend(), resume(), interrupt(), and terminate() methods, which do not seem difficult to implement. Beyond that, there are three fatalError() calls in the source file, which would need to be replaced with throws. There would also, of course, need to be “throws” annotations on the declarations for launch() and posix(), and “try” keywords added to the four calls to posix(). All told, not a large undertaking.

For backward source compatibility, the existing, non-throwing APIs could be provided as well, but deprecated. These could simply call the throwing APIs and either call fatalError() or throw an NSException when an error is caught.

I cannot think of too many instances where NSTask objects need to be passed around, so bridging to Objective-C is probably not a major concern.

IMPACT ON EXISTING CODE:

Since the new class would have the same name and public API as the existing Process (NSTask) class, this would not break source compatibility. It would break binary compatibility, which makes it a consideration for Swift 4.

Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170214/d9c1be42/attachment.html>


More information about the swift-evolution mailing list