Validating DroneOptions

[marcoff181]

Issue

At the moment if the Drone wants to do some checks on the DroneOptions passed during initialization, it can't return an error because of the trait:

fn new(options: DroneOptions) -> Self;

Why this limits Drone implementations

A group's drone that checks that the DroneOptions are correct (pdr within bounds, valid list of neighbors ...) could be a selling point for the fair, as it would make debugging the network initializer easier

Possible solutions

1. add return type Result to the Trait
2. leave it up to the groups to panic when there are incorrect DroneOptions, but specify in the protocol that a drone should panic if its Options are wrong(kind of obvious, but we need the protocol to be strict about these things otherwise a drone that accepts a pdr of 345.7 would be considered correct by the )
3. assume that given that network-initializer must create valid DroneOptions there is no need for the Drone to validate them

[DiCesareDaniele]

I would check this in the network initializer not in the Drone initialization

[matteo-dinoia]

I agree that is redundant but we could leave the option of people think is okay or want to initialize extra things that could fail if not setupped correctly.

[DiCesareDaniele]

I agree that is redundant but we could leave the option of people think is okay or want to initialize extra things that could fail if not setupped correctly.

This is bad tho since we have to buy other groups drone and we cannot ensure that a group is implementing the same checks that we are. But we can always validate DroneOptions before passing it to the drone

[matteo-dinoia]

Yeah, that is true. We could write that the result can only be used in case some needed resources cannot be initialized. But I guess in that case it could panics.

[marcoff181]

But we can always validate DroneOptions before passing it to the drone

Exactly, this is already a requirement in the network initializer, which means that when the network initializer works properly we don't need to worry if a Drone is doing the right checks on DroneOptions

Drones validating DroneOptions could be useful to know if your network initializer isn't working properly while you are developing it, and given that in this case there is no reason to recover from these errors a panic would be just fine

I don't know if we should specify in the protocol that a Drone should panic from incorrect DroneOptions. I just don't like the fact that a drone that accepts incorrect DroneOptions is considered correct in the protocol, even though in the final project we don't care because we are creating and validating DroneOptions before passing them to the drone.

[matteo-dinoia]

Voted against