Yes, I'm fine.
Am 17.09.18, 13:33 schrieb "Christofer Dutz" <[email protected]>:
How about discussing this in detail on Thursday?
Guess it will be easier to do this on such a basis ... of course we will
have to take the results of this discussion back to the list, but I guess it
should help in finding consensus on this issue.
What do you think?
Chris
Am 17.09.18, 11:58 schrieb "Sebastian Rühl"
<[email protected]>:
Hi,
Small addition for a rule of thumb:
If there is a prober/useful way to react to a error (from dev pov)
„user inputs data“ or something other a programmer might need to think about
for runtime error a checked exception is appropriate. For Errors which indicate
a programming error one should use Runtime Exceptions as theses errors should
occur in best case only one time (during development) and should bubble up
during unit tests.
Sebastian
> Am 17.09.2018 um 11:39 schrieb Julian Feinauer
<[email protected]>:
>
> Hey Chris,
>
> yes, checked exceptions and Lambda 8 are... kind of not perfect.
> Therefore I suggest the addition of an UncheckedInvalidFieldException
which wraps the checked exception for the lambda or the stream. This is similar
to how the JDK suggests to handle IOExceptions (with the UncheckedIOException).
>
> But I think the question is more about the user perspective than the
implementation and I see good arguments for both sides. And I do see the point
that its harder to react to this kind of exception but in a situation like ours
the reaction could be
> * more detailed exception (nobody cares about what kind of uncheked
exceptions are thrown from a function)
> * I see situations where this can lead to a runtime handling, e.g.,
givin the user another prompt to reenter or the possibility to fix its
configuration file and reload
>
> For me it just felt "unsafe" to just do the parsing and hope that
everything goes smooth, this is way I went to action.
>
> Julian
>
> Am 17.09.18, 11:32 schrieb "Christofer Dutz"
<[email protected]>:
>
> 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:
>
> collectionOfFieldQueries.stream().map(queryString ->
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)
>
> Chris
>
>
>
> Am 17.09.18, 11:27 schrieb "Julian Feinauer"
<[email protected]>:
>
> 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
>
>
>
>
>
