Chris's Wiki :: blog/python/ExceptionsOverlookProblem Commentshttps://utcc.utoronto.ca/~cks/space/blog/python/ExceptionsOverlookProblem?atomcommentsDWiki2014-10-31T20:24:37ZRecent comments in Chris's Wiki :: blog/python/ExceptionsOverlookProblem.By Jeremy on /blog/python/ExceptionsOverlookProblemtag:CSpace:blog/python/ExceptionsOverlookProblem:f85473a81b208794b3dfe76ef75eee6ab6a9081dJeremy<div class="wikitext"><p>Seems like more of a dynamic vs static typing problem than exceptions vs return values.</p>
<p>A dynamic language could return an undocumented error code that you could miss. A static language with checked exceptions can force you to deal with them. That's even more extreme of course, since you actually have to do work to ignore errors that you don't care about.</p>
</div>2014-10-31T20:24:37ZBy dozzie on /blog/python/ExceptionsOverlookProblemtag:CSpace:blog/python/ExceptionsOverlookProblem:0b6b2f1fe7fd0f3ad57a912afe69c5e2f4b1a6e7dozzie<div class="wikitext"><p>Erlang (and other functional languages, I guess) has this pretty much solved.
Erlang uses pattern matching:</p>
<pre>
{ok, Conn} = gen_tcp:connect("example.net", 80, [{packet, line}, {active, false}]).
</pre>
<p>If <code>gen_tcp:connect() </code> fails, it returns <code>{error, Something}</code>, which
causes pattern matching fail and exception to be raised. If the code needs to
handle such failures, programmer can write it like this:</p>
<pre>
case gen_tcp:connect("example.net", 80, [{packet, line}, {active, false}]) of
{ok, Conn} ->
do_something();
{error, Reason} ->
error_handling()
end.
</pre>
</div>2014-10-31T13:32:38Z