<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 12:27 PM, Brent Royal-Gordon via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">IMO, Java has it right - let the API designer decide which approach to take.<br class=""></blockquote><br class="">That's a frankly laughable misreading of the Java story. The Java story is that they wanted everyone to use checked exceptions, but the users loathed them so much that they found hacks to get around the checked exception system</div></div></blockquote><br class=""></div><div>+1. Been there, done that :)</div><div><br class=""></div><div>Another factor is that in the Java (and C++) environment, <i class="">nearly anything can fail</i>, since ‘new’ can throw an OutOfMemoryError*, and programmer mistakes like out-of-range array indexes or failed type-casts are treated as theoretically-recoverable exceptions. Therefore nearly any nontrivial method can potentially throw, so having unchecked exceptions is a requirement or else all of those methods would have to be labeled as ‘throws’.</div><div><br class=""></div><div>This is in contrast with Swift (and Go) where errors are higher-level — things like I/O errors — while assertion failures will unconditionally abort. This makes program logic a lot easier to follow, since the jumps caused by exceptions are notoriously unintuitive (being a form of invisible goto.)</div><div><br class=""></div><div>—Jens</div><div><br class=""></div><div>* This was reasonable in the 1990s, but makes little sense in the OSs most of us code for today, on which malloc() will pretty much never return NULL. (Embedded OSs are an exception.)</div></body></html>