https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/MDSAL-239 mdsal <p>In <a href="https://git.opendaylight.org/gerrit/#/c/53118/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/53118/</a> for <a href="https://jira.opendaylight.org/browse/NETVIRT-514" title="QosInterfaceStateChangeListener: java.lang.IllegalArgumentException" class="issue-link" data-issue-key="NETVIRT-514"><del>NETVIRT-514</del></a> I found myself writing a small utility with a method like this:</p> <p>Optional&lt;Uuid&gt; newUuidIfValidPattern(String possibleUuid)</p> <p>in class UuidUtil; about to be proposed into org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.types.rev130715.IetfYangUtil also.</p> <p>I'm wondering if this is an extreme rare case, or not something one might reasonably often encounter wanting to do - perhaps you would consider generating such a utility factory method returning an Optional for all classes generated for regexp expression in YANG, so that in the case of above org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.types.rev130715.Uuid would have this directly?</p> <p>Also see <a href="https://jira.opendaylight.org/browse/MDSAL-238" title="YANG gen. binding classes should offer a matches(CharSequence input) [or expose Pattern[] patterns public instead private]" class="issue-link" data-issue-key="MDSAL-238"><del>MDSAL-238</del></a> for a related more minor suggestion.</p> <p>Operating System: All<br/> Platform: All</p> MDSAL-239

YANG gen. binding classes with Optional<XYZ> newXYZIfValidPattern() kind of utility factory method

Improvement Resolved Won't Do Unassigned Michael Vorburger Wed, 15 Mar 2017 16:40:01 +0000 Fri, 9 Mar 2018 18:00:19 +0000 Tue, 18 Apr 2017 11:02:25 +0000 0 3 <p><a href="https://git.opendaylight.org/gerrit/#/c/53363/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/53363/</a> has a one of manual related thing (for Uuid); this issue basically proposes to generalize and auto-generate that kind of helper.</p> <p>Not sure if this has to be depending on <a href="https://jira.opendaylight.org/browse/MDSAL-237" title="Milestone: Implement Binding Specification - Java v2" class="issue-link" data-issue-key="MDSAL-237"><del>MDSAL-237</del></a> Binding Specification Java v2, or could already be done in v1 - what's the risk, after all?</p> <p>I guess this code is too long or slow for you?</p> <p> try </p> { maybeUuid = Optional&lt;Uuid&gt;.of(new Uuid(myString)); } <p> catch (IllegalArgumentException exception) </p> { maybeUuid = Optional&lt;Uuid&gt;.empty(); } <p>Binding Specification Java v2 currently does not plan to offer any "createIfValidElseEmpty" methods.</p> <p>&gt; } catch (IllegalArgumentException exception) {</p> <p>This isn't great, if for any reason code expects this path to be often travelled, then AFAIK catching an exception in a "normal" code path (not an "exceptional" one, which is supposed to happen rarely) is a bad anti-pattern with known performance issues on the JVM? I'm aware that there are some optimizations re. this deep in the JVM (e.g. if you throw/catch the same Exception a lot, then its skips creating a stack trace and you get weird exceptions which have no stack trace, apparently), but... this is a hack. IMHO you should check for something which you know may throw an exception by another mean, if you can.</p> <p>This is why I believe it could be valuable for gen. code to offer a util for this use case.</p> <p>Well, the question is, how do you expect to recover from having an illegal argument. To me it feels like the model and application are not aligned at all.</p> <p>&gt; how do you expect to recover from having an illegal argument. </p> <p>dunno, up to the calling code, thus the Optional. The scenario here is code à la: "if this String which I got from somewhere is a (some type, like Uuid) then I want to do that, otherwise I want to do this <span class="error">&#91;which may be nothing&#93;</span>".</p> <p>&gt; To me it feels like the model and application are not aligned at all.</p> <p>That's entirely possible, but I have run into at least one (c/53118/ for <a href="https://jira.opendaylight.org/browse/NETVIRT-514" title="QosInterfaceStateChangeListener: java.lang.IllegalArgumentException" class="issue-link" data-issue-key="NETVIRT-514"><del>NETVIRT-514</del></a>) real world need where having this would have been useful, and have thus opened this bug to suggest a general API to simplify the little handstand for a one-off solution for a particular type I'm making in c/53363 for future users of YANG binding gen. code.</p> <p>I agree with this sentence from <span class="error">&#91;1&#93;</span>:<br/> ideally, everything should be "strongly typed"</p> <p>For now, I think the performance hit is the appropriate punishment for an application "guessing" what the argument really is.</p> <p>The correct fix it to wait for <a href="https://jira.opendaylight.org/browse/MDSAL-49" title="Do not generate Builders for Union types" class="issue-link" data-issue-key="MDSAL-49"><del>MDSAL-49</del></a> and then implement maybe-uuid as a union type in a utility Yang model.</p> <p><span class="error">&#91;1&#93;</span> <a href="https://bugs.opendaylight.org/show_bug.cgi?id=7913#c1" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=7913#c1</a></p> <p>Hi Michael</p> <p>Have you got any more thoughts/conclusions about 7991 &amp; 7992 so we know if to confirm these bugs or not. Many thanks.</p> <p>&gt; appropriate punishment</p> <p>I don't like punishment...</p> <p>&gt; The correct fix it to wait for <a href="https://jira.opendaylight.org/browse/MDSAL-49" title="Do not generate Builders for Union types" class="issue-link" data-issue-key="MDSAL-49"><del>MDSAL-49</del></a> and then<br/> &gt; implement maybe-uuid as a union type in a utility Yang model.</p> <p>I see the idea (I think), but that hard-codes this into the model - I'm not sure you'd want that. There may truly be cases when from a model PoV something rightfully has regexp/lenght constraint, but you want to check some input against "could this be a" - without incurring the exception overhead? It seems, from what I understand, that <a href="https://jira.opendaylight.org/browse/NETVIRT-514" title="QosInterfaceStateChangeListener: java.lang.IllegalArgumentException" class="issue-link" data-issue-key="NETVIRT-514"><del>NETVIRT-514</del></a> was such a case - I doubt one would want to change the YANG model for Port in netvirt just because of that bug.</p> <p>&gt; more thoughts/conclusions about <a href="https://jira.opendaylight.org/browse/MDSAL-238" title="YANG gen. binding classes should offer a matches(CharSequence input) [or expose Pattern[] patterns public instead private]" class="issue-link" data-issue-key="MDSAL-238"><del>MDSAL-238</del></a> &amp; <a href="https://jira.opendaylight.org/browse/MDSAL-239" title="YANG gen. binding classes with Optional&lt;XYZ&gt; newXYZIfValidPattern() kind of utility factory method" class="issue-link" data-issue-key="MDSAL-239"><del>MDSAL-239</del></a></p> <p>personally I do still think both or at least one of these can be useful.. </p> <p>If it makes things easier if we choose just one of the two, then I think this issues captures the essence of the intended use case better than the lower level <a href="https://jira.opendaylight.org/browse/MDSAL-238" title="YANG gen. binding classes should offer a matches(CharSequence input) [or expose Pattern[] patterns public instead private]" class="issue-link" data-issue-key="MDSAL-238"><del>MDSAL-238</del></a>; so if you like we can keep this and close that one?</p> <p>But I do sense that Robert's &amp; Vratko's don't see this as something "critical" - and it's tree that you can work around it and achieve the same yourself in custom code; the point of this was to suggest an enhancement as a convenience short-cut when one wants to do this (which isn't every day, but the case has come up in the real world, thus I filed this). </p> <p>So if there is very strong disagreement, then just do just close it - this isn't the sort of issue I'd be inclined to "defend" or "fight for" <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/wink.png" height="16" width="16" align="absmiddle" alt="" border="0"/> at all - it was an idea which I thought of and basically still think has value, for some cases.</p> <p>&gt; you want to check some input against "could this be a"</p> <p>Is this check any different from "deserialize a union"?<br/> Unions should be modeled.</p> <p>&gt; but that hard-codes this into the model</p> <p>The union typedef can be in any model (that includes models typedefing the constituents). Any *-impl.yang will do.</p> <p>Michael, have you got any objections if I close this ticket? Thanks.</p> <p>&gt; Michael, have you got any objections if I close this ticket? Thanks.</p> <p>No objection, your honour.</p> Development External issue ID 7992 External issue URL Rank 0|i02x67: