[swift-users] "business applications market" flame

Jens Alfke jens at mooseyard.com
Thu Jan 7 16:56:35 CST 2016


> On Jan 7, 2016, at 2:33 PM, Don Wills <don.wills at portablesoftware.com> wrote:
> 
> Do you really believe that you can stop the "users" who "loathed them so much" from doing what they want to do with Swift?  Hubris isn't a strong enough word to describe that attitude.

It’s impossible to implement unchecked exceptions in Swift because it lacks any form of stack-unwinding. For example, if A calls B calls C, and B is not marked as ‘throws’, then there is no way for C to return an error back to A. (Unless the error is stored externally, like as an object property, instead of being directly returned.)

> FWIW, I've already started down the path of dealing with the lack of unchecked <whatever-you-call-em>s by using the following code:

“try!” isn’t anything like an unchecked exception. It simply ignores the error. It’s the equivalent of the unfortunate Java idiom:
	try {
		somethingThatMightThrowAnException();
	} catch(Exception e) { /* la la la I can’t hear you */ }
Back in my Java days I tracked several mysterious bugs down to usage of this idiom. Internally something was failing, but the exception was ignored so there was no indication of the failure. That made it much harder for me to find.

>     throw Exception("Invalid type")  /* for those types not supported which is a programmer error */

The correct way to signal a programmer error in Swift is with assert() or fatalError() [sp?]. Which removes your need to use the above workaround, because the method no longer needs to be marked as throws.

—Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160107/926d291a/attachment.html>


More information about the swift-users mailing list