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