File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Unreported exception Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Unreported exception" Watch "Unreported exception" New topic
Author

Unreported exception

Renter Becker
Greenhorn

Joined: Aug 15, 2009
Posts: 1


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
Lucas Alberione
Greenhorn

Joined: Aug 15, 2009
Posts: 8
Quick answer: you have to wrap the "problematic" call with a try/catch statement. Otherwise make the enclosing method throw com.phidgets.PhidgetException.

Can you post the line number in which this error is found?


Lucas
Lucas Alberione
Greenhorn

Joined: Aug 15, 2009
Posts: 8
As per javadoc line 42 should look something like:



javadoc: public void setOutputState(int index, boolean state) throws PhidgetException
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61106
    
  66

"Renter none", please check your private messages for an important administrative matter.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Lucas Alberione
Greenhorn

Joined: Aug 15, 2009
Posts: 8
This tuturial explains the concept of checked and unchecked exceptions.
Alec McLaughlin
Greenhorn

Joined: Aug 24, 2009
Posts: 1
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:

http://constv.blogspot.com/2009/08/error-handling-and-exceptions-in-java.html

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.

HTH,

Alec

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.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38519
    
  23
And welcome to the Ranch
Lucas Alberione
Greenhorn

Joined: Aug 15, 2009
Posts: 8
Let's not forget the original post's author just wanted to know why his code wasn't compiling. I think he's quite done.

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.


Hey, come on... give the Sun guys some credit...

How can you write a method and foresee what its callers would want to do with it in various scenarios.


That's called API design. For more, see this.


Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38519
    
  23
I could mention Campbell's rules about exceptions
  • 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.
    Mike Simmons
    Ranch Hand

    Joined: Mar 05, 2008
    Posts: 3013
        
      10
    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.

     
    jQuery in Action, 2nd edition
     
    subject: Unreported exception