barend / java-iban

An Apache licensed, immutable Java value type for IBAN's.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Failed to parse IBAN with CountryCode in lowercase

fano0001 opened this issue · comments

If we try to parse a IBAN e.g. de31 3002 0900 7500 0217 66 we got a

UnknownCountryCodeException: Unknown country code in input.

I expect that the parse method also can deal with countryCodes in lowercase.

A possible solution is to convert the substring of the countryCodes to uppercase.

Hi @fano0001,

Thank you for your feature request. I'm afraid this is something I will not support in the IBAN class.

The reason is that lowercase country codes are not a thing that exists within the IBAN specification. The IBAN Registry is unambiguous there; they just don't occur. I want to stay true to the specification. I appreciate that the parse(CharSequence) method is on the edge between valid and invalid, so your request is not necessarily at odds with that idea.

However, I choose to draw the line at validating the input without modifying the input.

If you want to make it easier for your users to enter an IBAN into some UI control by allowing them to input or dictate a lowercase country code, then I think it makes sense that the UI code assists the user by uppercasing the first two characters. The inverse is not true: if someone else in some other usecase wants to reject lowercase country codes, they should not have to write an additional, external check outside this library to do so.

The third option would be to provide some kind of "parse leniently" function, but that's an open ended domain with no single right answer. I don't want to go there.

Hi @barend
thx for your quick reply.

To Support our user we will uppercase the first 2 chars an then call parse.

commented

The third option would be to provide some kind of "parse leniently" function, but that's an open ended domain with no single right answer. I don't want to go there.

Hi @barend, I would like a 'parse leniently' function, but I understand your reasoning. Instead, would you consider formalizing the exceptions that java-iban can throw? For example, adding an interface IbanException and ensuring that all exceptions that java-iban throws extend from this interface? Then I can implement 'parse leniently' as

public IBAN parseIbanLenient(String input) {
  try {
    return IBAN.parse(input);
  } catch(IbanException e) {
    return null;
  }
}

I think this is possible at the moment because from a quick check I think that all exceptions extend IllegalArgumentException, but being able to specifically determine that an exception is because of a problem with IBAN validation would be much more convenient.

@aSemy sorry for the delayed reply, you posted while I was on vacation. I like your suggestion and I'll add an intermediate IBANException.