Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/spectrum3847/2026-Spectrum/llms.txt

Use this file to discover all available pages before exploring further.

Robot code runs in a hard real-time loop where an unhandled exception can crash the entire program mid-match. Spectrum follows a set of exception handling conventions that keep errors visible and recoverable without hiding bugs behind silent failures.

​
Core rules

An empty catch block swallows exceptions silently, making bugs nearly impossible to debug. At minimum, log the exception or print its stack trace.
Bad — hides errors completely
try {
    int value = mySensor.getValue();
} catch (IOException e) {
    // ← Don't do this
}
Good — always log the exception
try {
    int value = mySensor.getValue();
} catch (IOException e) {
    System.err.println("Sensor read failed: " + e.getMessage());
    Telemetry.print("SensorError: " + e.getMessage());
}
Catching Exception or Throwable generically can suppress critical runtime errors like NullPointerException or ClassCastException that should terminate or be handled specifically.
Avoid generic catch
} catch (Exception e) { // Too broad — masks real bugs
    e.printStackTrace();
}
Prefer specific exceptions
} catch (IOException e) {
    // Handle I/O failure specifically
} catch (TimeoutException e) {
    // Handle timeout specifically
}
Only catch Exception generically as a last resort in outer safety wrappers, and always log the full stack trace when you do.
NullPointerException and ArrayIndexOutOfBoundsException are the most common robot-crashing exceptions. Prevent them with conditional checks before accessing values.
java
// Null check before method call
if (myObject != null) {
    myObject.doSomething();
}

// Bounds check before array access
if (index >= 0 && index < array.length) {
    int value = array[index];
}
Network communication, sensor reads, and CAN bus operations can fail unpredictably. Wrap these with try-catch and fall back to a safe default value.
java
try {
    double distance = distanceSensor.getDistanceMeters();
    cachedDistance.update(distance);
} catch (RuntimeException e) {
    System.err.println("Distance sensor error: " + e.getMessage());
    // cachedDistance keeps its last good value
}

​
Custom exception classes

SpectrumLib’s util/exceptions/ package provides custom exception types for robot-specific error conditions. Use these instead of generic exceptions when throwing from library code so callers can catch them specifically.
java
// Custom exception example pattern (from spectrumLib/util/exceptions/)
public class MechanismNotAttachedException extends RuntimeException {
    public MechanismNotAttachedException(String mechanismName) {
        super("Mechanism not attached: " + mechanismName);
    }
}

​
The isAttached pattern

Mechanism hardware errors are often pre-empted entirely by the isAttached() guard in Mechanism.java. If a mechanism is not attached (i.e., the hardware is not present on this robot configuration), all control calls are no-ops and sensor reads return safe defaults — no exception needed.
java
// From Mechanism.java — hardware calls are gated by isAttached
public void setVoltage(double volts) {
    if (!config.isAttached()) return; // Safe no-op
    motor.setVoltage(volts);
}
Prefer the isAttached pattern for optional hardware over try-catch around motor calls. It’s cleaner and avoids CTRE library exceptions entirely.

Build docs developers (and LLMs) love

Get started for freeTalk to us