https://git.opendaylight.org/gerrit/#/c/53363/ has a one of manual related thing (for Uuid); this issue basically proposes to generalize and auto-generate that kind of helper.
Not sure if this has to be depending on MDSAL-237 Binding Specification Java v2, or could already be done in v1 - what's the risk, after all?
I guess this code is too long or slow for you?
try
{ maybeUuid = Optional<Uuid>.of(new Uuid(myString)); }catch (IllegalArgumentException exception)
{ maybeUuid = Optional<Uuid>.empty(); }Binding Specification Java v2 currently does not plan to offer any "createIfValidElseEmpty" methods.
> } catch (IllegalArgumentException exception) {
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.
This is why I believe it could be valuable for gen. code to offer a util for this use case.
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.
> how do you expect to recover from having an illegal argument.
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 [which may be nothing]".
> To me it feels like the model and application are not aligned at all.
That's entirely possible, but I have run into at least one (c/53118/ for NETVIRT-514) 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.
I agree with this sentence from [1]:
ideally, everything should be "strongly typed"
For now, I think the performance hit is the appropriate punishment for an application "guessing" what the argument really is.
The correct fix it to wait for MDSAL-49 and then implement maybe-uuid as a union type in a utility Yang model.
Hi Michael
Have you got any more thoughts/conclusions about 7991 & 7992 so we know if to confirm these bugs or not. Many thanks.
> appropriate punishment
I don't like punishment...
> The correct fix it to wait for MDSAL-49 and then
> implement maybe-uuid as a union type in a utility Yang model.
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 NETVIRT-514 was such a case - I doubt one would want to change the YANG model for Port in netvirt just because of that bug.
> more thoughts/conclusions about MDSAL-238 & MDSAL-239
personally I do still think both or at least one of these can be useful..
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 MDSAL-238; so if you like we can keep this and close that one?
But I do sense that Robert's & 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).
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" 
at all - it was an idea which I thought of and basically still think has value, for some cases.
> you want to check some input against "could this be a"
Is this check any different from "deserialize a union"?
Unions should be modeled.
> but that hard-codes this into the model
The union typedef can be in any model (that includes models typedefing the constituents). Any *-impl.yang will do.
Michael, have you got any objections if I close this ticket? Thanks.
> Michael, have you got any objections if I close this ticket? Thanks.
No objection, your honour.