montclairrobotics / footballshooterbot Goto Github PK

See commits agideon/FootballShooterBot@795c8dc and agideon/FootballShooterBot@18a269b as examples for what I'm about to describe.

The file src/main/java/frc/robot/core/Translator.java as of a74a296 has methods such as init() and periodic(). For the sake of consistency, and therefore ease of code understanding, I recommend that methods that will be called by the standard Robot methods such as robotInit(), teleopInit(), teleopPeriodic(), etc. be named with those same names. That is, Translator.init() should probably be named either robotInit(), teleopInit(), or autonomousInit().

To facilitate this, I created an interface declaring these methods. Unfortunately, it has not yet been merged into the central repository (it is pending #3) but you can see it at https://github.com/agideon/FootballShooterBot/blob/volatile/tryDecomposingRobot20191214/src/main/java/frc/robot/core/RobotLikeComponent.java. Implementing this interface lets a component object be contained within the componentsForDelegation data member in https://github.com/agideon/FootballShooterBot/blob/volatile/tryDecomposingRobot20191214/src/main/java/frc/robot/Robot.java, which in turn lets the standard Robot methods in that class dispatch invocations of the standard methods to those components in code such as:

@Override
  public void teleopInit() {
    componentsForDelegation.forEach((component) -> component.teleopInit());
  }

This issue appears in two places (that I have seen). I originally saw it in src/main/java/frc/robot/Robot.java in 97774ed, but it was also copied into src/main/java/frc/team555/FootballShooter/RobotLauncher.java before agideon@5b3ef8d.

I see also that it was copied to src/main/java/frc/robot/core/Launcher.java before 78b59aa.

The issue is two-fold: First, there is the code fragment:

            catch (Exception e) {
            ...
            }

and second, an expansion of this fragment is:

            catch (Exception e) {
                solenoid.set(false);
            }
            solenoid.set(false);

Of the two, the first part is the more significant so I'll cover that one first.

I understand that early programming classes give minimal coverage to error management. For most student-authored programs, errors aren't serious things (outside of trivialities such as one's grade, which impacts one's choice of college, which impacts one's future income, which impacts one's entire life, which impacts one's children, which impacts one's children's educations, which impacts one's children's lives, which impacts one's children's children's educations...). In robotics, though, it is important to recall that the software being built causes effects in the real world. Robots exist, they move, they act, and they react. Problems - errors that aren't managed properly - can have real-world effects. They can break hardware (which has happened). They can cause damage to walls or water fountains in hallways (which has happened). They can hurt people (??).

So care must be taken when dealing with errors. I'm going to provide a couple of references that I think are worth reading about error/exception management. But, as a rule, one generally doesn't want to catch and then (essentially) ignore every possible exception.

This answer - https://softwareengineering.stackexchange.com/questions/270406/is-it-a-good-practice-to-catch-all-exception/270417#270417 - makes the point that the point at which an error is handled is often far from where the error occurs. This may be especially true for a robot, where an appropriate default/generic response is most likely stop everything.

Another relevant point is #7 of the best practices described in https://stackify.com/best-practices-exceptions-java/, which is "Don’t Ignore Exceptions".

That's the first point. The second point may introduce a new concept, and it's one worth knowing: finally.

A finally block is semantically related to a catch block. It is based upon a try block. The difference, though, is that while a catch block only executes under certain conditions, a finally block is guaranteed to execute. That guarantee is a strong one (see https://stackoverflow.com/questions/3779285/exception-thrown-in-catch-and-finally-clause for a mind-stretching example and some good explanations).

In the code fragment cited above, if any exception it thrown from within the try block, the catch block is executed and solenoid.set(false) occurs. Because the exception is caught at that point, the code following the try/catch block is executed and solenoid.set(false) occurs again. While that's probably not a problem in this case - I'd guess that solenoid.set(false) is idempotent - that may not always be true. To assure that solenoid.set(false) occurs exactly once regardless of whether an exception is thrown and/or caught or not, use:

            catch (Exception e) {
                ...
            }
            finally {
                solenoid.set(false);
            }