In order to solve <
# development
In order to solve I’d like to optionally resolve
. This has come up a few times before as well, where it would be desirable to not throw a
for invalid/unknown addresses (as they may be something else, too) 🧵
I don’t think it is very difficult to solve, but are there any concerns you have how we go about this?
I’m considering adding a new bool field to
that you can flip in order to get back `Address`es for all your inputs, but where addresses are gifted with a
boolean property that you can examine to see if it was indeed resolved properly or not.
I wrote some hacky code to optionally parse strings as addresses when dealing with Maven coordinates. It just catches any exceptions. See
Yeah, thats almost good, however in this case, the string may be formatted as a valid address (and I want it resolved if it indeed is an address too) into a
So I could catch the engine
I guess, but then it doesn’t interact well when I have a list of such addresses, some of which may throw..
Huh… so, looking at @hundreds-father-404’s Spec changes to implement ignores, I realise that maybe treating unparsed addresses as specs would actually work in this case, as there’s already implemented support for “unmatched glob behaviour” which I think will do what I want when set to “ignore”.
💯 1
Oh cool! Yeah, there is 🙂
🙌 1