转载

URL 强制解包带来的问题

作者：Erica Sadun，原文链接，原文日期：2017-01-06

译者：星夜暮晨；校对： Crystal Sun ；定稿： CMB

让我先阐述一下撰写这篇文章的背景。 Laptopmini 想要知道为什么下面这段代码无法完成编译。诚然，Swift 的错误提示尚存有改进的余地。简而言之：他需要将第二行和第三行代码进行互换，才能够完成编译。这就需要让这两个属性在引用 self 之前，完成初始化操作。

URL 强制解包带来的问题

我很快将目光放在了这些感叹号上。「是否存在会导致 URL 构建失败的情况呢？如果有，为什么不去阻止这些潜在的崩溃发生呢？」Laptop 指出：他的 URL 在任何情况下都不会发生异常，因此在这里使用感叹号进行强制解包是非常安全的。

除此之外，他的这种做法也让我的代码洁癖发作了。无论如何，URL 都不应该在这个构造器当中创建。我在想应该有更好的方法来进行处理，也就是将 URL 的构造从构造器当中移出，并且辅以完好的错误处理，以便获得更佳的错误消息提示。

首先，对 URL 进行扩展，以提供一个更为安全的非空构造器 (non-optional initializer)。以下代码片段提供了「安全着陆」的功效，当某个字符串无法构造成 URL 的时候，提供有用的反馈信息。

extension URL {
    /// 非空构造器能够提供更好的错误输出
    public init(safeString string: String) {
        guard let instance = URL(string: string) else {
            fatalError("Unconstructable URL: /(string)")
        }
        self = instance
    }
}

不过对这个问题而言，似乎有点小题大做。因此，我推荐使用这种方案：在 SocketEndPoint 类型当中添加相同的方法。

// 返回 `URL`，同时也可以明确指出错误
public enum SocketEndPoint: String {
    case events = "http://nowhere.com/events"
    case live = "http://nowhere.com/live"
    
    public var url: URL {
        guard let url = URL(string: self.rawValue) else {
            fatalError("Unconstructable URL: /(self.rawValue)")
        }
        return url
    }
}

这种方法使得他的初始化方法更加简洁明了。基于这种新的设计，我们在构造器当中使用标准化的 URL，不再使用强制解包。

// 改造过的构造器
fileprivate init() {
    self.eventSocket = WebSocket(url: SocketEndPoint.events.url))
    self.liveSocket = WebSocket(url: SocketEndPoint.live.url))
    self.eventSocket.delegate = self
    self.liveSocket.delegate = self
}

总而言之：

字符串枚举的确很方便，但是 SocketEndPoint 却没有做好它自己的职责。它的工作应该是提供合法的 URL。无论类型实现的方式如何，它都应该提供这样的功能。物尽其用，既然在语言内部存在一个「差不多」的解决方案，何乐而不为呢？
让构造器保持干净和整洁；
在权衡通用的全局解决方案和简单的本地解决方案的时候，有些时候最好从简单的方案着手，尽量在紧邻的上下文之间就解决好相关的问题。
我觉得使用正常的 URL 构造器（返回有可空值），然后再创建一个带有隐式可空值解包（ public init(url: URL!) ）的 WebSocket 构造器并没有带来任何好处，当字符串的结构出现异常的时候，就没有办法报告这个错误。此外，还十分地丑陋。

您可以在这个 gist 当中看到我所提及的这几种方法。

本文由 SwiftGG 翻译组翻译，已经获得作者翻译授权，最新文章请访问http://swift.gg。

原文 http://swift.gg/2017/01/13/holy-war-forced-unwrapping-urls/

正文到此结束