<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 31 May 2018 at 02:41, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
</span>Since error messages are rarely part of the exception API, testing for <br>
them is fragile and prone to errors. For example, what if the message <br>
changes to "no money" or "out of funds" or "insufficient funds" or <br>
"keine Mittel"? Since the error message is not part of the API, that can <br>
happen at any time, without warning.<br></blockquote><div><br></div><div>The messages are from constraint triggers in the database.</div><div>I'm the author of them.</div><div><br></div><div></div><div> <span></span><br><span></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
</span>The obvious way to do that is to create BeyondLimit and NoFunds <br>
subclasses of DatabaseError. Why can't you do that?<br></blockquote><div><br></div><div>Because I'm not the author of DatabaseError.</div><div>It's an ORM exception or a database driver class exception,</div><div>something I'd need to monkeypatch to change.</div></div><br><div class="gmail_quote"><br></div><div class="gmail_quote"><span></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
</span>That seems like a backwards way to do it to me. If you're the author of <br>
the exception class, why not just subclass your exceptions the regular <br>
way and get a real subclass?<br></blockquote><div><br></div><div>I agree. Problem is: I'm not the author of the exception class,</div><div>and I'm not raising/throwing their exception instances.</div><br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On 31 May 2018 at 04:19, Terry Reedy <span dir="ltr"><<a href="mailto:tjreedy@udel.edu" target="_blank">tjreedy@udel.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As Stephen said, messages are intentionally not part of the defined API. [...]<br></blockquote></div><br></div><div class="gmail_extra"><div>We could check error numbers instead of meaningful strings.</div><div><div>I'm thinking on technical error keys in either way.</div></div><div><br></div><div></div><div class="gmail_extra">Previously to classes like FileNotFoundError, we would need to check</div><div class="gmail_extra">an OSError errno. There were no alternative:</div><div class="gmail_extra">Python users are not the author of "everywhere that raises OSError".<br></div><div class="gmail_extra"><br></div></div><div class="gmail_extra">Another example is urllib.error.HTTPError.</div><div class="gmail_extra">We can have a specific handler code for a given HTTP error code.</div><div class="gmail_extra">Yet we don't change urllib.request.urlopen to raise something else</div><div class="gmail_extra">for that specific error code.</div><div><br></div><div></div><div><br><div class="gmail_quote">On 31 May 2018 at 06:29, Stephan Houben <span dir="ltr"><<a href="mailto:stephanh42@gmail.com" target="_blank">stephanh42@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>"[...] The exception matching machinery ignores the __instancecheck__ mechanism."<span class="m_-5657164968120001842gmail-HOEnZb"><font color="#888888"><br></font></span></div></div></blockquote><div><br></div></div></div><div>The <span style="font-family:monospace,monospace">__subclasscheck__</span> gets bypassed, as well.</div><div></div><div><br></div><div>-- </div><div class="gmail_extra"><div class="m_-5657164968120001842gmail_signature" data-smartmail="gmail_signature">Danilo J. S. Bellini<br>---------------<br>"<i>It is not our business to set up prohibitions, but to arrive at conventions.</i>" (R. Carnap)<br></div>
</div></div>