In the current revision of the paper (r3) the discover_topology function is permitted to throw an exception in case of a failure in discovering the system's topology. However, this could be problematic as this failure could prevent a library dependant on this discovery from functioning, even if the failure had nothing to do with the resources the library was looking to utilise.
A solution to this could be support partial error in topology discovery, where calling discover_topology could be permitted to fail but still return a valid topology structure representing the topology that was discovered successfully. The way in which these errors are reported (i.e. exceptions or error values) would have to be decided, exceptions could be problematic as it could unwind the stack before capturing important topology information.
Hm, the speeds-and-feeds bit could be trouble. What happens if I discover a device, find out my bandwidth to it, but something bad happened when trying to find the bandwidth from it to me?
In the current revision of the paper (r3) the
discover_topology
function is permitted to throw an exception in case of a failure in discovering the system's topology. However, this could be problematic as this failure could prevent a library dependant on this discovery from functioning, even if the failure had nothing to do with the resources the library was looking to utilise.A solution to this could be support partial error in topology discovery, where calling
discover_topology
could be permitted to fail but still return a valid topology structure representing the topology that was discovered successfully. The way in which these errors are reported (i.e. exceptions or error values) would have to be decided, exceptions could be problematic as it could unwind the stack before capturing important topology information.