Made PlcInvalidFieldException.java checked.

[JulianFeinauer]

Made PlcInvalidFieldExeption checked, added UnchekedInvalidFieldException and changed everywhere.

[sruehl]

We should discuss if this is the right way to go. In my opinion errors like these should always be runtime errors as theses a programming errors (e.g. ArrayIndexOutOfBoundException) and can't be handled properly at runtime so no need to check them. In contrast if this error could happen at runtime like a connection drop for reconnects etc. than it worth to enforce the catching of this exception so the developer can implement his own handling of this. But in this case in most cases the try catch wouldn't contain any useful code as the address ist unlikely to change at runtime (errors resulting in a parsing error).

(// TODO How should this be handled? might be exactly the point im trying to make ;))

[JulianFeinauer]

Hi @sruehl I think I cannot answer to your question directly, I think.
I get your point and in these points you point out it's true that I do not know what the appropriate handling is.
I opened a dicussion thread on the list to exchange the arguments and find a common understanding :)

[JulianFeinauer]

Hey @chrisdutz and @sruehl just wanted to bump that up. I think we should decide here on something and either merge or decline the PR. What do you hink about the checked exceptions for wrong user inputs?

[sruehl]

As I said: The annoyance to be forced to catch a exception would outweigh the benefit. In the usual api use this would a one-time-occur-exception so we would require the developer to pollute the code with catch(e) new RuntimeException(e) snippets. So I would suggest/vote to close this PR and maybe pickup the topic in later releases (if at all).

[JulianFeinauer]

Closing as suggested by sebastian.
But I definitly like to adress the topic nonetheless as we heavily depend on user input which can always be errorous.