Do I have to take a look at the java api everytime I instantiate an object / call a method from a class in it? Also, do I always have to know which classes are in the java api and which are not?
If the exception is checked, then the java compiler will force your invoking method to either catch the exception or declare that it could throw the exception.
If the exception that is thrown inherits from Error or RuntimeException - I.e. is unchecked, then you have no way of knowing besides javadoc and looking at the code.
A good example of the latter, is NumberFormatException, thrown by Double.parseDouble(String). The only way to know is that the javadoc tells you it could throw this exception.
Modern IDEs (Eclipse, Netbeans, IntelliJ etc) provide easy access to this documentation.
I use Eclipse IDE which will make sure you account for all thrown exceptions. I highly recommend it.
http://www.eclipse.org
Knowing what exceptions a function throw is not different from knowing what arguments it needs, and what type it returns.
You either know it, look it up, or use an IDE that does this for you. BTW for checked exceptions you will get a compile-time error, so that can also be an option.
For you second question, In general...
Packages that start with "java." or "javax." are in the J2SE API.
Most packages starting with a internet domain prefix like "com." or "org." are supplied by third parties. Don't count on com.sun being stable though.
Packages with none of prefixes the above are likely not following the package naming guidelines or predate them.
Related
Should one re-throw a runtime exception as a checked exception, where a client could sensibly anticipate and handle the situation.
It seems to me that is the purpose of checked exceptions, and surely since such anticipatable and handleable scenarios can occur in runtime exceptions as well as checked exeptions - would it not make sense to treat them the same.
Should one do this through listing runtime exceptions in the throws clause - and hope? Does rethrowing it as a user defined checked exception help in this respect (by forcing through the compiler a client to handle it)?
Edit:
(for instance where one might encounter a NumberFormatException when reading files that may be supplied)
RuntimeExceptions are basically logical errors. And logical errors should be corrected in code instead of throwing them across your code base.
Exceptions are scenarios which occur rarely but when do, the flow of program changes drastically.
You CAN wrap a RuntimeException into a checked exception but That's NOT recommended. A logical error in your method is not supposed to be handled outside your method and more bad if you providing your method to be used as an API to other developers.
To add one more point, If you are developing a framework it seems logical to throw the RuntimeException so that developers can handle it by correcting their code but if you are developing a library, be far far away from doing that.
To know difference between framework and library see this: What is the difference between a framework and a library?
I am using "java.lang.reflect.Type" in web app project all working fine..but I am stuck with code review how to fix "java.lang.reflect.Type illegal package import " -checkstyle warning..
I am more intrested in explanation of this warning.
Thanks
The original IllegalImport check only forbids the sun.* packages, so you are looking at a custom rule definition made by your client.
The rule simply means that you are not supposed to use classes from certain packages. This can make sense for various reasons. If your rule forbids java.lang.reflect.Type, then your client does not want you to use Reflection.
Since you say that you may not modify the rules, you will have to find some way to reach your goal without Reflection.
Usually packages that are for internal use and version specific. They can be dropped/modified anytime. Like sun.*. Look for anything that is not by default in your Checkstyle config.
Reference.
I used abort() In C to make my program crash. And debugger will trap this.
Maybe equivalent in Java should be exception. But Java also has very strict exception chaining policy, so using of exception for debugging purpose doesn't seem to be a good idea.
What should I use for this in Java? Intentional program crash for debugging purpose which can be trapped by debugger. (I am using Eclipse)
Update
It would be very nice if the code can be optionally opt-out on release build.
In Eclipse you can set debug points, and run in debug mode.
That said, there is a difference between a CheckedException (which must be caught by the calling function or passed up the chain) and an UncheckedException (which is closer to what you want). Throw the latter if you want to force a crash.
However, this is generally a bad way to program. You'll find better results using alternative means to catch the errors you want.
You can use assert(false). Assuming you're using Eclipse for the debugger, you can set Eclipse to break on specific exceptions (in this case, AssertionError). Make sure you enable assertions, otherwise it won't do anything.
Since you have to explicitly tell the JVM to enable assertions, I think this would count as "code [that] can be optionally opt-out on release build."
I do not know how to handle it in Eclipse. However, under JDB, this can be done by catching the Exceptions. Eclipse should have such an interface.
Using command line like this
"catch java.io.FileNotFoundException"
For details, please refer to here
My application uses some third-party libraries. I need to log some exceptions that occur inside lib (e.g. exceptions about read file), but these exceptions are caught in the same library.
Is there some way I can log these exceptions myself, even if they're not logged by the library?
Look at AspectJ. You can write an advice around construction (and maybe even thrwoing) of the FileNotFoundException. Be advised though, that it will log every time the the pointcut is reached. With some expertise you will be able to control it.
EDIT: Dave Newtwon pointed at at this example which shows how easy it is to do this once you get the hang of it.
When using GWT I get following warning:
Referencing deprecated class 'com.google.gwt.user.client.rpc.SerializableException'
While it's only a warning, it's dead annoying having to look at every single time I run the project.
The warning occours since my RPC throws java.lang.Exception, and thus never actually uses the SerializableException, but GWT isn't clever enough to figure that out.
Is there a option to turn off the warning, or fix this, besides compiling my own version of the gwt-user/gwt-servlet libraries?
Thanks.
Edit: To clarify, this is GWT 2.0, and the project is being run from the Google Plugin in Eclipse.
Someone on the GWT's Google Group suggested using SerializationException instead of just Exception. Although, the javadocs for SerializableException suggest that Exception should be fine too :/ Which version of GWT are you using?
Deprecated. As of GWT 1.5, Exception
implements Serializable and can be
used in place of this [SerializableException] class
Lombardi's blog has a discussion of why exactly this is happening in the source.
Yeah, it's silly for Google to claim throwing Exception is a fine thing to do when it generates a lot of unnecessary JavaScript for subclasses of Exception and, in your case, generates warnings about those subclasses.
But this is all the more reason to throw a more specific exception (one that doesn't have a deprecated descendant). Unchecked exceptions on your RPC can still be handled by an UncaughtExceptionHandler.
You could set the loglevel of the gwt compiler. It seems like you have set yours to "warn", set it to info to get rid of the message.
If you are using eclipse do the following steps:
right click on the project
Google >> GWT Complie
Set the Log Level to info
Although extending SerializationException is a workaround, the contract of SerializationException indicates that it should not be used as a parent class of your custom RPC exceptions. It's there to indicate issues with the serialization itself and not with the logic within your services.
The underlying issue is that the compiler generates unnecessary code. To avoid the error simply make sure that your code does not use SerializableException anymore and add the following line to your module descriptor.
<extend-configuration-property name="rpc.blacklist" value="com.google.gwt.user.client.rpc.SerializableException"/>
Once the compile issue is fixed, you can remove the line again. Here is a link to the issue you might wanna star/follow:
http://code.google.com/p/google-web-toolkit/issues/detail?id=4438