plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <>
Subject Re: [DISCUSSION] Exception handling during Parsing
Date Mon, 17 Sep 2018 09:32:34 GMT
Hi Julian,

I can imagine that ... we were having some discussions about stuff like that. 
The thing is, that a checked exception should give the application a chance to react to something.
If we use an invalid address, there's sort of nothing we can do about that. And while I like
checked exceptions too ... all this Lambda Java 9 stuff seems to have problems with them.
They seem to get gobbled up without notice. Runtime exceptions however seem to be able to
bubble up.

Also do Checked exceptions make it difficult to write code like this: -> builder.addField(queryString));

So with these runtime exceptions you have the ability to catch them and react on them, but
you don't make things too complicated for people using Lambdas.

Hope I got this right (Sebastian, please correct me if I got this wrong)


Am 17.09.18, 11:27 schrieb "Julian Feinauer" <>:

    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
    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

View raw message