Go to Post I in all sincerity thoroughly enjoy the way that programming for FIRST makes me want to bash my head against a wall. - pogenwurst [more]
Home
Go Back   Chief Delphi > Technical > Programming > Java
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 12-02-2012, 22:28
Brian Selle's Avatar
Brian Selle Brian Selle is offline
Mentor
FRC #3310 (Black Hawk Robotics)
Team Role: Engineer
 
Join Date: Jan 2012
Rookie Year: 2012
Location: Texas
Posts: 170
Brian Selle has a spectacular aura aboutBrian Selle has a spectacular aura aboutBrian Selle has a spectacular aura about
Exception Handling Best Practice

We are using java with a command based robot. I wondering how others are handling java exceptions... do you try-catch exceptions in the public subsystem methods, command methods, or just let the framework handle them?

In general, I'm just trying to prevent a total meltdown if I don't catch something.
Reply With Quote
  #2   Spotlight this post!  
Unread 12-02-2012, 22:42
Patrick Chiang Patrick Chiang is offline
Programming
FRC #3070 (Team Pronto)
Team Role: Mentor
 
Join Date: Feb 2009
Rookie Year: 2009
Location: Seattle
Posts: 162
Patrick Chiang is a name known to allPatrick Chiang is a name known to allPatrick Chiang is a name known to allPatrick Chiang is a name known to allPatrick Chiang is a name known to allPatrick Chiang is a name known to all
Re: Exception Handling Best Practice

Use try-catch. But most importantly, keep them separate, and put them at the end of any piece of code that only runs once.

That way, if the camera suddenly gets unplugged during a competition, your robot won't just sit there and wait until it gets image.

Here's a (very real) example of what might cause problems:
Code:
public void robotInit(){
    try {
        // camera init code
        // joystick init code
        // jaguar init code
    } catch (Exception ex){
        ex.printStackTrace();
    }
}
If your camera code is broken, the joystick and jaguar init code will not execute, and your robot will not run. The solution is to take the joystick and jaguar init code out of the try-catch.

Try-catch blocks aren't a cure for cancer, or robot crash. What you want to do with try catch is to make sure that you're anticipating possible errors, like camera taking time to boot up before it's ready to get image, components breaking in the middle of a competition, wires becoming unplugged.

You want to make sure that if something is broken, everything else (that doesn't depend on it) still works. THAT, I believe, is the point of catching exceptions.

Some people might take issue with me try-catching using a general exception, but I disagree and would actually recommend that for competition. You want to make sure nothing silly escapes your try-catch and crash your robot.
Reply With Quote
  #3   Spotlight this post!  
Unread 15-02-2012, 17:10
sjspry sjspry is offline
Registered User
FRC #1984
Team Role: Programmer
 
Join Date: Jan 2011
Rookie Year: 2010
Location: Kansas
Posts: 125
sjspry has a spectacular aura aboutsjspry has a spectacular aura aboutsjspry has a spectacular aura about
Re: Exception Handling Best Practice

While you shouldn't ignore the exceptions which crop up, that doesn't mean you have to handle them - when possible, I just declare them as thrown all the way up to the top. If something happens, it will crash the robot.

This might sound like a bad thing, but the common exceptions, like those thrown by the functions to create an AnalogChannel, etc, are configuration problems and wouldn't be likely to be recoverable anyway.

The other common one is InterruptedException. You might not be able to throw it (if you get one in the inhereted method of Runnable.run()), and in this case, you should feel safe just eating it - catch it and do nothing. The only thing that will generate an InterruptedException on the cRIO would be user code, as in, you would have to explicitly interrupt that thread for it to happen.

When in doubt, just throw it.
Reply With Quote
  #4   Spotlight this post!  
Unread 16-02-2012, 09:36
Brian Selle's Avatar
Brian Selle Brian Selle is offline
Mentor
FRC #3310 (Black Hawk Robotics)
Team Role: Engineer
 
Join Date: Jan 2012
Rookie Year: 2012
Location: Texas
Posts: 170
Brian Selle has a spectacular aura aboutBrian Selle has a spectacular aura aboutBrian Selle has a spectacular aura about
Re: Exception Handling Best Practice

Thanks for the input. I've updated our code to try-catch during the init process as Patrick mentioned and throw when there is something catastrophic. One of the reasons I asked was for the CANTimeoutException. We are using CAN and most methods on the CANJaguar throw this exception so we have try-catches everywhere. Don't know if there is anything to do with this... I just increment an error counter and display it to the SmartDashboard. Oddly enough the place I get most of these CANTimeoutExceptions is in the updateStatus() method used to send data back to the SmartDashboard.
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 12:37.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi