System.InvalidCastException in Lextm.SharpSnmpLib.Messaging.MessageFactory.ParseMessage

[RedwoodForest]

We just saw this System.InvalidCastException thrown from SharpSnmpLib in our app (using SharpSnmpLib v12.3.0).

I don't have any information about the SNMP request/response that caused the exception.

System.InvalidCastException: Unable to cast object of type 'Lextm.SharpSnmpLib.NoSuchInstance' to type 'Lextm.SharpSnmpLib.Integer32'.
   at Lextm.SharpSnmpLib.Messaging.MessageFactory.ParseMessage(Int32 first, Stream stream, UserRegistry registry)
   at Lextm.SharpSnmpLib.Messaging.MessageFactory.ParseMessages(Byte[] buffer, Int32 index, Int32 length, UserRegistry registry)
   at Lextm.SharpSnmpLib.Messaging.SnmpMessageExtension.<GetResponseAsync>d__19.MoveNext()

[Lex Li]

Without supporting data we can only assume the agent returned a message that was not compliant with the standards.

[RedwoodForest]

Thanks for the info @lextm.

The issue for us here (and for the similar #159) is the type of exception thrown in cases like this when the server we're communicating with is not compliant with the standards.

Because we make connections to arbitrary SNMP servers we cannot ensure that the servers we're communicating with are always compliant with the standards so we need to handle this case in our code. With the current approach of throwing exceptions like InvalidCastException and ArgumentOutOfRangeException it means we cannot distinguish bugs (in our code or the library) from a non-compliant response from the server. If instead SnmpException were thrown in cases like this it would be handled by our existing code for handling communication issues.

To use Eric Lippert's terms InvalidCastException and ArgumentOutOfRangeException generally indicate a boneheaded exception, but these cases seem like exogenous exceptions instead (because we don't control what the server we're communicating with returns), so it seems like something like SnmpException should be thrown instead.

Hope that's helpful and we really appreciate all the work you do on this library.

[Lex Li]

No plan to support non-compliant agents, as they require hacks that do not really contribute to any other users of this library.