Unreported exception com.phidgets.PhidgetException; must be caught or declare to be thrown
This is the error I am encountering. What am I missing here? Also any comments on the code would be helpful. What I am doing is connecting to a RFID reader then reading the chip. However if it reads a certain chip I want it to activate the first output that is built in to the reader but I am running into this small problem. This is the API Reference from the phidgets site. http://www.phidgets.com/documentation/JavaDoc.zip Index.html > RFIDPhidget > setOutputState
Your exception handling here looks kind of strange. First, your main() declares "throws Exception" instead of handling all exceptions inside. That's wrong. Since your main process is, indeed, your application, why are assuming that it's ok for it blow up? You need to catch any exceptions that reach the top level of your application - e.g. your main() - and handle them in a graceful way, even if they represent programming errors. At the very least you need to catch, log the full stack trace, and display a more or less friendly message to the user. Logging will ensure that the error info does not get lost, but it is not necessary to spew the exception in the face of the user (assuming that you logs may go into separate files for admins to look at, while the console output is more "user friendly".) In other words, you should put a try/catch/finally around the main() method. In your other methods (subroutines) you can handle specific exceptions that you want to handle in a distinct way. No need to handle and rethrow anything else. Just let everything else propagate to the catch in main(). This would save you lots of time mand effort placing unnecessary try/catches in almost every method.
Another issue that I see is that your methods catch (and, perhaps handle or swallow) a specific type of checked exception, and nothing else. What this means is that you may catch that specific exception but let other (runtime) exceptions slip through the cracks and go unreported. It is never enough to handle just the checked exceptions because they are only a subset of all exceptions that may occur in your application.
There is an excellent article I have recently read:
I highly recommend reading it. It answered a lot of my questions, and it explains things much better than I can. I think it is one of the better ones out there on exceptions and error handling in general.
P.S. As for the Sun's "tutorial" on handling exceptions, I think it is very obsolete and just wrong. They recommend using checked exceptions "when the client is expected to recover"... That is just wrong. How can you write a method and foresee what its callers would want to do with it in various scenarios. Some may want (be able) to recover, some might have no knowledgeof how to handle the error immediately and would have to propagate that exception further. Why impose such contract on everybody instead of simply broadcasting the error and letting whomever is interested to listen to it and catch it? Again, read the article I had mentioned above, it explains things well, I think. Ever since I read it i have been recommending it to everyone.
Every rule about Exceptions, never mind how hard-and-fast, has exceptions.
The number of conflicting opinions about Exceptions is equal to the number of people asked.
That article is quite assertive, and I agree that presenting end-users with a stack trace is guaranteed to confuse them. Also some RuntimeExceptions (eg NumberFormatException) can probably be recovered from. And some checked Exceptions (eg some IOExceptions) cannot be recovered from without stopping the application. But are you really going to recover from an ArrayIndexOutOfBoundsException caused by writing a for loop incorrectly? Agree with the article that you shouldn't throw and handle the same Exception in the same place. But do you really want them all to propagate to the main method? Once you get there, all you can do is log them and shut down gracefully; you have abandoned any chance of recovery.
On the flip side, I think there are a few cases where declaring main with "throws Exception" is perfectly legitimate. One is in cases where I (or another programmer) am the end user of the application. In this case I don't give a crap about presenting a nice, carefully neutered error message to the user. I just want to see the stack trace. Why should I write a try/catch for this, when the JVM will already do it for me? It's just more visual noise at that point.
The other case is when the programmer is a beginner (as in, "Beginning Java", ahem). Frankly, many beginners can't yet handle exceptions very well. And I have seen too many beginners write try/catch blocks which catch an exception and issue a useless message like "something bad happened", without also logging the exception in a more useful manner. Or who, after catching the exception and maybe even logging it, then proceed on with whatever they were trying to do, even if it's completely pointless now because of the exception. E.g. if you got a FileNotFoundException when you tried to open a FileReader, there's really no point to trying to read the file after that. In such cases I think it's more sensible to encourage simply letting an exception be thrown, even from a main method, as a default, first-pass exception handling strategy. At least until the programmer has a better understanding of how exceptions work in the first place, and how to log them without losing important information. In most cases I'd much rather have a confused end-user than an error for which I have no stack trace from which to diagnose a problem.
I think in many ways I agree with much of what Alec (and the referenced article) have to say. But I reject the dogma that having a main() that "throws Exception" is categorically wrong. It isn't. There are often much better solutions, true, but not always.