
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;">This sounds like a good idea to me. The distinction of a parameter error, a not-implemented error and a known bug in an implementation (that one I hadn't added yet, only proposed) is one that the user is probably not interested in at all. So this makes for a good replacement for all three.</div><div style="direction: inherit;"><br></div>Sent from my iPhone</div><div><br>On 22 Aug 2016, at 18:50, Robert Goldman <<a href="mailto:rpgoldman@sift.net">rpgoldman@sift.net</a>> wrote:<br><br></div><blockquote type="cite"><div><span>What about an UNSUPPORTED-FUNCTIONALITY ERROR subclass?</span><br><span></span><br><span>I was thinking of putting it in UIOP, and exported, for the use of cases</span><br><span>where a particular implementation doesn't support an operation.</span><br><span></span><br><span>This might make it much easier to handle implementations that don't</span><br><span>support all operations, PARTICULARLY in test cases.</span><br><span></span><br><span>Best,</span><br><span>r</span><br><span></span><br></div></blockquote></body></html>