Properly managing errors in WPILib

What’s the proper way to receive errors in WPILib C++? Constructing an ADXRS450_Gyro, for example, will return just the gyro, even it fails to construct (e.g. because there is no gyro). Let’s say I want to use WPILib (or the HAL) to read and understand this fact, so that I can act accordingly (i.e. do whatever I want. I may want to try again, but I may also want to try on a different SPI port for whatever reason).

I’ve seen HAL_GetLastError, but I imagine that won’t be the easiest to use for error messages in, say, motor controllers, since it only provides the status code, and there are tons of controllers on the robot - it could be caused by one any of them!

Generally, we’ve actually changed most objects to throw exceptions on construction. However, the gyros are not one of the ones that have been changed (at least currently). I’m actually not sure if there’s a way in those to detect if construction has failed. We definitely should add one

1 Like

Okay, thanks, that’s unfortunate :).

We do not want to throw an exception in this case. Think about what this means for your robot in a match if the sensor is accidentally disconnected right before you put it on the field… having running code with no gyro is infinitely better than not having any running code at all.

We only want to throw on something that is clearly a configuration error in code (e.g. resource conflicts), not on problems that could be intermittent.

It probably would be useful to provide an isConnected() function or similar for your “fallback” style use case.

1 Like

That’s also something that would be great to put on a fault monitor dashboard widget.

Okay, that seems to make the most sense for me, ty.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.