Hi all,
I just opened a PR where I made the PlcInvalidFieldException checked.
Sebastian commented on the PR and states that he would prefer an unchecked
Exception.
So I suggest we discuss the matter and think about the exception handling
strategy.
Why do I think a checked exception is better?
When users use plc4j they provide their own address and source strings. Here,
three kinds of failures can occur:
* The string contains an error (e.g. copy paste)
* The string does not belong to the connection (S7 address for Beckhoff
connection)
* The address does not exist
The third case is handled later on.
But I assume the first two errors to be (at least) equivalent frequent if not
far more common to occur.
Thus, I prefer to notify the code users to handle this case explicitly to give
their users feedback that they entered a “bad string”.
Futthermore, especially in stream processing contexts things like
Try {
// do something…
} catch (Exception e) {
Logger.warn(“Problem during processing of element…. “)
}
Is used.
From my perspective, the case where I have bad input data is different and
would, if catched and logged silently lead to a number of equal log entries, as
each processing step would simply fail.
In this case I think its important to notify the stream developer of the fact
that he cant event start his stream processing.
Sebastian states:
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 would in most
cases don't contain any useful code as the address ist unlikely to change at
runtime (errors resulting in a parsing error)
What do others think, how should we generally deal with User Input and checked
/ unchecked exceptions?
Julian
