You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Julian Feinauer <j....@pragmaticminds.de> on 2018/09/17 09:26:50 UTC
[DISCUSSION] Exception handling during Parsing
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
Re: [DISCUSSION] Exception handling during Parsing
Posted by Julian Feinauer <j....@pragmaticminds.de>.
Yes, I'm fine.
Am 17.09.18, 13:33 schrieb "Christofer Dutz" <ch...@c-ware.de>:
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" <se...@googlemail.com.INVALID>:
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 <j....@pragmaticminds.de>:
>
> 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" <ch...@c-ware.de>:
>
> 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" <j....@pragmaticminds.de>:
>
> 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
>
>
>
>
>
Re: [DISCUSSION] Exception handling during Parsing
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <se...@googlemail.com.INVALID>:
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 <j....@pragmaticminds.de>:
>
> 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" <ch...@c-ware.de>:
>
> 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" <j....@pragmaticminds.de>:
>
> 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
>
>
>
>
>
Re: [DISCUSSION] Exception handling during Parsing
Posted by Sebastian Rühl <se...@googlemail.com.INVALID>.
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 <j....@pragmaticminds.de>:
>
> 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" <ch...@c-ware.de>:
>
> 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" <j....@pragmaticminds.de>:
>
> 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
>
>
>
>
>
Re: [DISCUSSION] Exception handling during Parsing
Posted by Julian Feinauer <j....@pragmaticminds.de>.
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" <ch...@c-ware.de>:
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" <j....@pragmaticminds.de>:
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
Re: [DISCUSSION] Exception handling during Parsing
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <j....@pragmaticminds.de>:
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