<div dir="ltr">True but in my example above for parsing a JSON into a model I can do this:<div><br></div><div>class Model {</div><div><br></div><div>let property: String</div><div>let property1: String<br></div><div>let property2: String<br></div><div>let property3: String<br></div><div><br></div><div>init?(json: [String: AnyObject]) {</div><div><br></div><div>guard property = json[&quot;property&quot;] as? String else {</div><div> return nil</div><div>}</div><div><br></div><div><div>guard property = json[&quot;property1&quot;] as? String else {</div><div> return nil</div><div>}</div></div><div><br></div><div><div>guard property = json[&quot;property2&quot;] as? String else {</div><div> return nil</div><div>}</div></div><div><br></div><div><div>guard property = json[&quot;property3&quot;] as? String else {</div><div> return nil</div><div>}</div></div><div><br></div><div>}</div><div><br></div><div>}</div><div><br></div><div>There is a lot of boilerplate for very little information and I&#39;m worried by letting people initialize without returning an error we will get complex objects like this being constructed and failing for no reason. </div><div><br></div><div>Compare this to error handling:</div><div><br></div><div><div>class Model {</div><div><br></div><div>let property: String</div><div>let property1: String<br></div><div>let property2: String<br></div><div>let property3: String<br></div><div><br></div><div>init?(json: [String: AnyObject]) throws {</div><div><br></div><div>property = try json.require(&quot;property&quot;)</div><div>property1 = try json.require(&quot;property1&quot;)</div><div>property2 = try json.require(&quot;property2&quot;)<br></div><div>property3 = try json.require(&quot;property3&quot;)<br></div><div><br></div><div>}</div><div><br></div><div>}</div></div><div><br></div><div>Require reads the key from the dict and tries to cast it to the same type as the variable its being assigned to and throws an error if this fails (like it doesn&#39;t exist or it can&#39;t be casted). This has much less boilerplate, its easier to read and also we can throw an error saying (&quot;We couldn&#39;t parse property1&quot;). </div><div><br></div><div>Some frameworks like Freddy JSON so something similar to this but with a much more complex model using Enums and it involves setting a bunch of parameters to tell the library when to throw a runtime error or not if it can&#39;t find something which if not handled correctly can cause a crash.</div><div><br></div><div>We could make this even simpler yet if we could somehow treat casting as an error:</div><div><br></div><div><div>class Model {</div><div><br></div><div>let property: String</div><div>let property1: String<br></div><div>let property2: String<br></div><div>let property3: String<br></div><div><br></div><div>init?(json: [String: AnyObject]) throws {</div><div><br></div><div>property = try json[&quot;property&quot;] as String</div><div>property1 = try json[&quot;property1&quot;] as String</div><div>property2 = try json[&quot;property2&quot;] as String<br></div><div>property3 = try json[&quot;property3&quot;] as String<br></div><div><br></div><div>}</div><div><br></div><div>}</div></div><div><br></div><div>If casting fails it throws an error, unfortunately we lose error information about the key so probably having a casting method like the one above is probable better. But in someways it explains what is happening.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">







<p><b><font color="#cc0000">___________________________________</font></b></p><p><b>James⎥Head of Trolls</b></p><p><b><font color="#cc0000"><a href="mailto:james@supmenow.com" target="_blank">james@supmenow.com</a>⎥<a href="http://supmenow.com" target="_blank">supmenow.com</a></font></b></p><p><b><font size="2">Sup</font></b></p><p><b><font size="2">Runway East
</font></b></p><p><b><font size="2">10 Finsbury Square</font></b></p><p><b><font size="2">London</font></b></p><p><b><font size="2">
EC2A 1AF </font></b></p></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Mar 3, 2016 at 8:59 AM, Brent Royal-Gordon via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; Error handling forces you to do something about the possibility of a failure.<br>
<br>
</span>So does using a failable initializer: the value is in an Optional, so you can&#39;t access it without either testing and unwrapping or just force-unwrapping. The type system, rather than the `try` requirement, is what forces you to handle the error, but it&#39;s the same idea.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>