<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 Aug 18, 2017, at 3:24 AM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">The only practical merit of typed throws I have ever seen someone demonstrate is that it would let them use contextual lookup in a throw or catch. People always say "I'll be able to exhaustively switch over my errors", and then I ask them to show me where they want to do that, and they show me something that just logs the error, which of course does not require typed throws. Every. Single. Time.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><br class=""><div class="">I think the aspect of documentation shouldn't be underestimated:</div><div class="">People want to know what might go wrong — even if they have only a single reaction to all cases at their disposal.</div></div></div></blockquote><div><br class=""></div>There's no reason we couldn't do some tooling work to expose emergent information about what kinds of errors are thrown by the current implementation of a function, and maybe even check that against the current documentation. Certainly, it should be possible to document particularly interesting errors that a function might throw. I'm just challenging the idea that this should be reflected and enforced in the type system.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Typed throws could also help to lessen the tight coupling to Objective-C:</div><div class="">Being forced to declare conformance to a protocol without requirements or even public methods feels very awkward to me.</div></div></div></blockquote><div><br class=""></div>Error is not about Objective-C interop; we could make the feature work without a protocol, and in fact the protocol alone isn't sufficient for what we try to do with it. The protocol's value is mostly communicative, a way of making it obvious that a type is meant to be thrown, as well as to verify that you aren't accidentally throwing something nonsensical.</div><div><br class=""></div><div>It also gives us a hook to add defaulted requirements in a later release.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">In some way, throws are typed already, but there's just one type allowed, and it can't be changed.</div><div class=""><br class=""></div><div class="">Imho the big problem of the whole topic is the bad experience people had with typed throws in Java; I don't see a problem in adding typed throws and keeping Error as default type to be thrown if nothing else is specified.</div></div></div></blockquote><div><br class=""></div><div>The problems people have with typed throws in Java aren't ultimately because of some specific failure of Java (although there are certainly ways in which Java's design could be better in my opinion). They pretty much all arise directly from conceptual problems with the idea of "restricted" sets of errors.</div></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">If people want to build huge lists of possible errors… why not? As long as I'm still able to write my own throwing functions as today, I'm fine with that.</div></div></div></blockquote><div><br class=""></div></div>Language features have to meet a higher bar than "why not?".<div class=""><br class=""></div><div class="">John.</div></body></html>