[swift-evolution] [Discussion] Adopting a new common error type outside the bounds of NSError

[Kevin Ballard]

I can see the benefit in having a basic error type for use with alerts
and such, but arguably that's what NSError is for (although NSError
doesn't pick up context info). A downside to the type you're proposing
is it doesn't provide any way to programmatically indicate what went
wrong (the strings are presumably for human consumption, not
programmatic introspection), which makes it largely useless for anything
except the point where you're about to hand off an error to the UI for
display (where it's too late to gather context info).

Also I disagree that the codes can be better represented as strings.
Strings are presumably for human consumption, but error codes are for
programmatic consumption. You don't want to do string comparisons to
figure out what type of error it is. And of course codes themselves are
obsoleted by having strong type information, which is what Swift already
has with concrete ErrorType implementations.

-Kevin Ballard

On Sun, Mar 6, 2016, at 09:17 AM, Erica Sadun via swift-evolution wrote:
> NSError encapsulates runtime error condition information. It uses an
> historic, time-tested object built to communicate information to users
> and provide a basis for workarounds. Swift's redesigned error
> mechanism differs significantly from NSError in that its primary
> consumer are API calls, via the try-catch mechanism and not end-users.
>
> I would not like Swift to be tied down to an archaic construct for the
> sake of consistency. NSError's core domain/code/userInfo attributes
> are architected to archaic use-cases. It domains of
> Mach/POSIX/Carbon/Cocoa are subsumed by Swift modules. The integer-
> based codes can be better represented by plain-text strings, the
> dictionary keys model usage that poorly integrates into Swift's throw-
> try ecosystem.
>
> To me, an error should answer the following questions:
>
> * What went wrong?
> * Where did it go wrong?
> * What other information am I passing along about the circumstances of
>   the error?
>
> A universal standard library error could be as simple as
>
> struct Error: ErrorType {  let reason: String }
>
> although, I'd far prefer to add a context, using the newly updated
> debug literals to describe exactly where the error sourced from. An
> ideal context[1] would include:
>
> * A source location including a fully qualified module, file name and
>   line number, shared  object (dsohandle), symbol, e.g.
>   FooType.methodName(label1: _, label2: _) (with an optional  mangled
>   name component), and column number (although I sincerely do not
>   understand   the point of column number)
> * An indicator of release or debug build
> * Pre-crafted strings that combine these data into printable forms
>   suitable for release and  debug output using brief, long, and
>   exhaustive context forms.
> * Decomposable elements, offering both the full context story while
>   retaining an option  to access and query individual components as
>   needed.
>
> struct Error: ErrorType {  let reason: String  let context:
> ContextType }
>
> further, I'd want to implement some kind of generalizable
> dictionary, an infoDictionary rather than a userDictionary, that
> describes error circumstances and possible recovery selectors,
> without being tied to the notion that the ultimate consumer[2] is an
> NSAlert presented to a user.
>
> struct Error: ErrorType {  let reason: String  let context:
> ContextType  let infoDictionary: Dictionary<String: Any> }
>
> -- Erica
>
>
> _________________________________________________
> swift-evolution mailing list swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



Links:

  1. http://ericasadun.com/2015/08/27/capturing-context-swiftlang/
  2. https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/ErrorObjectsDomains/ErrorObjectsDomains.html#//apple_ref/doc/uid/TP40001806-CH202-CJBGAIBJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160306/488dd633/attachment.html>