<div dir="ltr">On Mon, Aug 19, 2013 at 5:24 PM, Tom Ellis <span dir="ltr"><<a href="mailto:tom-lists-haskell-cafe-2013@jaguarpaw.co.uk" target="_blank">tom-lists-haskell-cafe-2013@jaguarpaw.co.uk</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
On Mon, Aug 19, 2013 at 05:15:39PM -0400, <a href="mailto:jabolopes@google.com">jabolopes@google.com</a> wrote:<br>
> But I would like to see more code move away from exceptions and into<br>
> types like "Maybe" or "Either" or other types defined for the<br>
> particular situation (as some people were suggesting in the beginning<br>
> of the thread). And the reason for this it is because when you program<br>
> against types you have to make a decision whether to handle the error<br>
> or let it bleed through: you can't ignore the choice because you can't<br>
> ignore the type. On the other hand, with exceptions, you can easily<br>
> forget to handle the exception if you're not looking at the<br>
> documentation at the time when you write the code.<br>
<br>
</div>This is /exactly/ the reason to avoid exceptions where possible.<br>
<span class=""><font color="#888888"><br>
Tom<br>
</font></span><div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>And tangentially related, it's why Go uses error return values (with functions being able to "return multiple values"), e.g. <a href="http://blog.golang.org/error-handling-and-go">http://blog.golang.org/error-handling-and-go</a></div>
</div></div></div>