<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On Feb 16, 2017, at 8:26 PM, Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">1. Is there anything developers can do today to use FileHandle safely in Swift? There doesn’t seem to be, which seems to me to justify rather extreme measures to fix the problem. As it stands right now FileHandle shouldn’t be used from Swift on Apple platforms, which is a rather poor experience all around.</div></div></blockquote><div><br class=""></div><div>Yeah, it is a bit of a ticking time bomb on Swift. So is Process/NSTask.</div><br class=""><blockquote type="cite" class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">2. How can the issue be fixed for Swift? I think part of (or most) the reason Charles originally suggested using the open source Foundation implementation was because of the (apparently) severely breaking changes that would be required on the Apple Foundation side to actually fix the issue. I also think a lot of the frustration in this thread came from the fact that these APIs have been known not to conform to best practices for over a decade now and yet haven’t been fixed, which then descended into complaints about Apple’s dev process in general. Not productive but I think indicative of the logic behind Charles original suggestion that the open source implementation be used instead of Apple’s. Correct me if I’m wrong Charles.</div></blockquote><div><br class=""></div><div>Currently the only way to handle a runtime error with either of these classes is to catch the exception, and parse it. So if you changed NSFileHandle itself, you’d have to make the existing API into a wrapper over the new one, catching the errors and converting them into exactly the same exceptions as before. Obviously it’s doable, but it just seemed easier to use the existing open-source implementation to me. If Tony says they’ll fix the Objective-C implementation in Foundation, though, I certainly won’t complain if that happens.</div><br class=""><blockquote type="cite" class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">It’s clear that there’s more here than just an evolution proposal for a new Swifty FileHandle API. What should the process be for proposals which may also require underlying Apple framework changes, like this one? A proposal for a new API that also references Radar(s)? Get the changes from Apple first and then make the proposal? Or a separate proposal that suggests a mechanism for implicitly catching Objective-C exceptions as Swift errors? This clearly should be fixed, so how should it be done?</div></blockquote></div><br class=""><div class="">I don’t think Objective-C exceptions should be caught as Swift errors. 99% of the time, they’re not things that should be caught, and we ought to just get rid of that remaining 1%.</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>