NFD » ndn-cxx

I can confirm a problem based on visual inspection of the code. All NFD management modules rely on ManagerBase::extractParameters to catch exceptions thrown by ControlParameters::wireDecode (rib-manager uses RibManager::extractParameters, but it's the exact same code).

However, extractParameters only expects an ndn::Tlv::Error. It seems that ControlParameters::wireDecode can also throw a ControlParameters::Error:

• "expecting TLV-TYPE ControlParameters"
• "expecting Strategy/Name"

Obviously I can add the additional exception type to ManagerBase/RibManager::extractParameters, but I'm not sure if that's the correct fix. Should wireDecode only throw ndn::Tlv::Errors ?

ControlParameters::Error is a subclass of Tlv::Error

What about control command? Do we handle validation of control parameters?

I think so. ManagerBase/RibManager::validateParameters catches ControlCommand::AgrumentErrors thrown by validateRequest.

I just noticed Component::wireDecode throws a Component::Error which inherits directly from std::runtime_error. However, I'm not sure this code is actually being called.

Could this be causing a problem?

static_cast<LocalControlFeature>(readNonNegativeInteger(*val))

I found this: http://stackoverflow.com/questions/11551853/can-static-cast-throw-an-exception-in-c

Hmm. name::Component::Error could be the problem. I'll re-assign this to myself and check exceptions in the library. I think these should be inherited from Tlv::Error as well.

I just noticed in the doxygen (http://named-data.net/doc/ndn-cpp-dev/0.4.0/doxygen/d8/d0b/classndn_1_1nfd_1_1ControlCommand_1_1ArgumentError.html) that ControlCommand throws another exception that is not derived from Tlv::Error/std::runtime_error.

Is ArgumentError properly handled?

As far as I can tell. The only method the management modules use that throws an ArgumentError is ControlCommand::validateRequest. This call is wrapped in an appropriate try catch in ManagerBase/RibManager::validateParameters.

The management modules also use ControlCommand::applyDefaultsToRequest, but that family of methods doesn't throw any exceptions.