> On 07 Dec 2017, at 17:02, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
>
> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> This seems marginally tolerable, but excessive.
>>
>> Do we mark every usage of a type that can generate precondition failures or
>> fatal errors for reasons other than “no such method?” No, we don’t.
>>
>
> fatalError shouldn’t be used excessively. API surface areas for these types
> are going to be massive (infinite technically). I assume many people are
> going to be writing a lot of code would these types and calling many methods
> and properties which would all essentially have a fatalError. Would you
> consider it good code if the majority of all your types had methods defined
> with fatalError calls.
>
> What is the basis for this claim? Probably the majority of standard library
> methods check preconditions and trap on failure. That is how I write my code
> as well.
>
I’m talking specifically about fatalError not precondition. fatalError is
something that goes out with production code while precondition is used for
debugging. I think you would agree a shipped program that has many states of
being unrecoverable is not a good design?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
