Add nullable support throughout the whole library. #293
Conversation
|
I assume this is the motivation for #296 ? I did not realize that this did not work with Visual Studio 2017 - haven't used it in a long time. But great to see that you seems interesting in potentially supporting it. I have come to really like nullable support for all my projects even for .NET Framework things. It really helps detect NullReference exceptions and to be more explicit about which variables are nullable and which are not. |
|
Adjusting S7NetPlus to have nullable annotations should not affect any user of the library, unless nullable support is enabled there as well. It is after all just a compiler-internal annotation, and does not change anything about the fact that reference type variable can still be null. |
This requires reference types that can be null to be annotated by a ? operator, similar to value types. This gives the advantage that the compiler can warn against any null dereference exceptions, of which this commits elimits a few. To make the underlying protocol implementation not any more complicated and to eliminate existing problems, and not that precise error reporting, I replaced some return null statements with explicit Exceptions. This lead to the assumption that those core protocoll functions always return non-null objects if they do not throw, making the PLC code simpler. Adjust some NotConnected tests to look for explicit PlcException instead of NullReferenceException.
|
HI @scamille, I understand how the feature works, I just meant that I wouldn't enable nullable reference types on a 10k+ lines codebase if there's no obvious reason to do so (or at least professionally, since I can't substantiate the investment with regards to the benefits). Nevertheless, I'm happy that you made this change, merging right away. |
2 participants
This requires reference types that can be null to be annotated by a ? operator, similar to value types.
This gives the advantage that the compiler can warn against any nullreference exceptions, of which this commits elimits a few.
To make the underlying protocol implementation not any more complicated and to eliminate existing problems, and to give more precise error reporting, I replaced some return null statements with explicit Exceptions. This lead to the assumption that those core protocol functions always return non-null objects if they do not throw, making the PLC code simpler.
Adjust some NotConnected tests to look for explicit PlcException instead of NullReferenceException.