> On Feb 14, 2017, at 7:18 AM, Charles Srstka via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> MOTIVATION:
>
> In Swift 3, NSFileHandle was renamed to FileHandle, making it the de facto
> file handle class for use in Swift applications. Unfortunately, it’s not a
> very good API. NSFileHandle supports no error reporting whatsoever, instead
> throwing Objective-C exceptions whenever something goes wrong during reading
> or writing. There is no way that I know of to catch these exceptions in
> Swift, meaning that if a write failed because the disk ran out of space or
> something, there’s no way to deal with that other than crashing the whole
> application.
>
> In addition, NSFileHandle’s asynchronous API is broken. It provides a
> readabilityHandler property which allows blocks-based reading of files, but
> this handler does not provide any way to detect when the end of the file is
> reached, which makes it not useful for many applications.
For what it's worth, the readability handler is intended to be an analogue to
select, kevent, or DISPATCH_SOURCE_TYPE_READ, not an async reading mechanism
itself. Using real async IO like readInBackground* will be more efficient, and
get you the EOF handling you expect. It's somewhat unfortunate that this
relatively specialized API ended up looking so much more appealing than the
more generally useful one, and that's something that could be improved in the
future.
David
>
> PROPOSED SOLUTION:
>
> Rename FileHandle back to NSFileHandle, and provide a Swift-native FileHandle
> class for Foundation in Swift 4 that mimics NSFileHandle’s interface, but
> provides throwing versions of all the read and write methods:
>
> open class FileHandle : NSObject, NSSecureCoding {
> open func readDataToEndOfFile() throws -> Data
>
> open func readData(ofLength length: Int) throws -> Data
>
> open func write(_ data: Data) throws
>
> // etc.
> }
>
> Much of the work for this is already done, in the swift-corelibs-Foundation
> project. The main thing that would need to be done for the synchronous APIs
> would be simply to replace the fatalErrors with throws, a simple enough
> operation. The asynchronous read/write APIs are still unimplemented in
> corelibs, but given that a new implementation of those based on DispatchIO
> could be engineered in such a way that it would correctly report EOF, the
> benefits to the end-user would likely justify the expense.
>
> 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.
>
> Since FileHandle is just a wrapper around a file descriptor, bridging to
> Objective-C should not be difficult; just use the file descriptor from one
> side to build a handle on the other side.
>
> IMPACT ON EXISTING CODE:
>
> Since the new class would have the same name as the existing FileHandle
> class, as it is exposed to Swift, this would not break source compatibility.
> It would break binary compatibility, which makes it a consideration for Swift
> 4.
>
> Charles
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
