• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Unreported exception

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 Alberione
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As per javadoc line 42 should look something like:



javadoc: public void setOutputState(int index, boolean state) throws PhidgetException
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Renter none", please check your private messages for an important administrative matter.
 
Lucas Alberione
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This tuturial explains the concept of checked and unchecked exceptions.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And welcome to the Ranch
 
Lucas Alberione
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
     
    Master Rancher
    Posts: 4806
    72
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.

     
    It's a pleasure to see superheros taking such an interest in science. And this tiny ad:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic