SafeIterativeRobot

[virtuald]

One thing we've done in previous years is add things like this to our robot, so that unexpected crashes don't kill our robot when we're in a real match.

try:
    some_statement()
except:
    if not self.isFmsAttached():
        raise

It seems like this is something that could be added to the IterativeRobot::startCompetition function around each call to user code in the various modes, so that it's harder to accidentally kill your robot during a competition. Obviously java doesn't have the same risk of problems as we do, so it makes sense for them to not have exception handlers around the calls to user code. However, the risk in python is significantly higher.

I think this is a core thing that should be added to RobotPy.. or maybe to the extension library. But definitely something standard that teams can use. If it were added to core robotpy, I'd probably just add it to IterativeRobot... that way teams don't have to think about it too much.

If we wanted to really push command-based robots, we'd probably wrap each one of those calls with the same thing. But... that seems like a lot more work.

[virtuald]

If @PeterJohnson or @computer-whisperer don't think this belongs in core, then I'll probably implement it and put it in the extension library (which is currently installed by default).

[computer-whisperer]

I do think it is a great idea, and is something that all teams should probably do. In this case, I would vote for it to be put in robotpy-ext.

In addition, I think that we should draw a line somewhere as to what features go in robotpy-ext and what features go here.

I think an adequate test would be: If you were to take any random java wpilib program and completely port it to python, would you need the proposed component?

[virtuald]

Well, 'need' is an interesting term to define here.

I think that it's ok to deviate from the Java implementation if they are features that stay in the spirit of WPILib, and meet a language specific need (as stated in the design goals document).

I think that this functionality is something that would benefit every team that uses RobotPy, and helps make the RobotPy platform more stable to use in a competition situation. Therefore, I think it's an addition that we should make to the core IterativeRobot, as this will help a lot of people, and I cannot currently think of any negative consequence (maybe adding an exception handler will add some overhead? probably not).

Java doesn't need this type of thing because of unchecked exceptions aren't going to happen particularly often. In python, unchecked exceptions are how we roll.

[virtuald]

I think this sort of thing will have to be a separate framework type thing.