search

arturmkrtchyan / iban4j

A Java library for generation and validation of the International Bank Account Numbers (IBAN ISO_13616) and Business Identifier Codes (BIC ISO_9362).
http://iban4j.org
Apache License 2.0
276 stars 125 forks source link

Checked exceptions #11

Closed mpkorstanje closed 10 years ago

mpkorstanje commented 10 years ago

Right now all IBAN format exceptions are runtime exceptions. Yet the client code is actively constructing and validating ibans, it can be reasonably expected to recover from iban formatting problems.

"Runtime exceptions represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way." from -http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html

mpkorstanje commented 10 years ago

If it is any help I can make the fixes and submit a pull request but I rather do so knowing before hand the changes will be accepted.

arturmkrtchyan commented 10 years ago

@mpkorstanje, I personally favor unchecked exceptions. It's not an easy decision but however community is moving towards using more unchecked exceptions rather than checked ones. The good thing is that if you want still you can catch desired unchecked exceptions.

Your argument applies also to Integer.parseInt(String str), Integer.valueOf(String str), new BigDecimal(String str) but again here unchecked NumberFormatException has been chosen.

mpkorstanje commented 10 years ago

There are two very general cases in which you are converting strings to numbers. Either you are reading stored data. Or you are dealing with user input.

When reading stored data you assume it to be in a fixed format. If the format is not correct then there is nothing the client code can do to solve that. In this situation using an unchecked NumberFormatException is correct.

When dealing with user input you also have to take into account regional preferences for the decimal and thousands separator. Integer.parseInt() and friends simply aren't suited for this. You can use it as a shortcut, everybody who ever starts with Java does, but you really shouldn't.

While I can still catch the exceptions. This is not my motivation for asking and doesn't really deal with my issues. Now I don't know about the community but I think the original guidelines from Java are quite sufficient. Checked exceptions force you to deal with the exceptional situation or propagate the responsibility upwards. This responsibility is then automatically documented and enforced by the compiler. This has a load of advantages.

Right now I'll have to check in the code to see if no other exceptions are thrown, with an upgrade I'll have to check the API to see if exceptions have been added or removed, ect. All in all allot more work to ensure the code doesn't do anything unexpected.

arturmkrtchyan commented 10 years ago

You should always check the API regardless Exceptions are checked or unchecked, and if the API is documented good enough you don't need to walk through the code to check exceptions, additionally you should have enough test cases covering exceptional cases so with the new library upgrade your code is not failing or relying only on compiler.

While I see your point and it's not big effort to make these exceptions checked I would still like to use unchecked ones. Think about C# which has a lot of Java concepts but they decided not to have checked exceptions.

mpkorstanje commented 10 years ago

Ah sorry my mistake. I'll have to check the bloody implementation, not the API, for things a compiler can catch.

edit: I'm sorry to see you prefer checked exceptions. You've given no advantages reasons other then that you like it.