I'm new on Java, and I would like to know if Java has something like Python exception handling, where you don't have to specify the exception type. Something like:
try:
f = open('text.tx', 'r')
except:
#Note you don't have to specify the exception
print "There's an error here"
I hope you can help me.
Yes there is something called the try and catch block it looks something like this:
try
{
//Code that may throw an exception
}catch(Exception e)
{
//Code to be executed if the above exception is thrown
}
For your code above it could possibly be checked like this:
try
{
File f = new File("New.txt");
} catch(FileNotFoundException ex)
{
ex.printStackTrace();
}
Hope this helps look at this for more information: https://docs.oracle.com/javase/tutorial/essential/exceptions/
Every exception in Java is some sort of extension of java.lang.Exception. So you can always do:
try {
// something that maybe fails
} catch (Exception e) {
// do something with the exception
}
It will catch any other type of exception, you just won't know what the actual exception is, without debugging.
You can't leave out the exception type, but the widest try-catch block would be:
try {
// Some code
} catch(Throwable t) {
t.printStackTrace();
}
which catches Exceptions, Errors and any other classes implementing Throwable that you might want to throw.
It would also be incredibly foolish to use that anywhere, especially in something as simple as file access. IOException is a checked exception, so whenever you're doing file operations you'll be reminded by the compiler to handle that exception. There's no need to do a catch-all, it only makes your code more brittle.
Related
Code:-
try {
Assert.assertEquals("1", "2");
} catch (Exception e) {
System.out.println("I am in error block");
}
If the assert statements fails, I would like to capture the error in the catch block. I am trying with the above code and its not happening.
Will the assertion error be caught by in a catch block for java exception?
You have almost answered your own question. Your catch block will not catch the AssertionError that the Assert throws if it fails, because it is an Error (or, more specifically, it extends java.lang.Error). See the docs for more information on this. Your catch block only catches Throwable objects that extend java.lang.Exception
If you really want to catch it - you need to use
catch (AssertionError e) {
...
However, as others have mentioned, this is a very unusual way to use assertions - they should usually pass and if they fail it is very unusual for you to want to carry on the program execution. That's why the failure throws an Error rather than an Exception. You can read more about (not) catching Error in this question.
If you just want a test the variable value, it is preferred to use if ( variableName == "1")
NB if you are testing unit-test helper code, like a matcher, it might make sense to catch the AssertionError.
If you want to catch both Exception and Error instances use:
...
catch (Throwable t)
{
...
}
Since both Exception and Error extend Throwable.
Well, I believe you are using JUnit for writing your tests. In that case, you should not catch your Assert.assertEquals() because they should pass for normal test execution. If it throws any exception, it means that your code is not performing as it should.
If you want to catch the errors in that way you need something like the following:
if (num == 1 || num == 2) {
throw new Exception();
}
You could create your own exception class and pass in the message you want.
If you run following code then it will compile and run successfully,
public class Example {
public static void main(String[] args) {
// insert code here
try {
new Example().go();
// throw new OutOfMemoryError();
} catch (Error e) {
System.out.println(e);
}
}
void go() {
go();
}
}
With following output :
java.lang.StackOverflowError
So my question is "Can we catch an Error"..??
Answer to your question is yes, you can catch error in java. And your code is almost correct. Your method go() calls itself infinitely and therefore causes StackOverflowError that is caught in your catch block and printed by System.out.println()
Yes, you can catch an Error, but you are advised not to do it, since Errors indicate serious problems that a reasonable application should not try to catch. (as stated in the Javadoc of Error)
Yes, we can catch an error.
The Throwable class is the superclass of all errors and exceptions in the Java language. Only objects that are instances of this class (or one of its subclasses) are thrown by the Java Virtual Machine or can be thrown by the throw statement.
Similarly, only this class or one of its subclasses can be the argument type in a catch clause. For the purpose of compile-time checking of exceptions, Throwable and any subclass of Throwable that is not also a subclass of either RuntimeException or Error are regarded as checked exceptions.
try {
while(true) {
}
} catch (Throwable e) {
// TODO: handle exception
System.out.println(e);
}
Note that there's a difference between StackOverflowException and StackOverflowError, since you have an error, it's a serious indication that you should never try to catch it.
Just don't do infinite things in your code, when this error happens, no stack space is available, how would you want to proceed?
StackOverFlowError indicates that you have severe problems, it's a bad idea to catch this error, instead, try to understand what problems you have in your code and fix them.
I'm trying to debug a libgdx application... Obviously, I'm producing a NullPointerException at some point, but libgdx has a huge try-catch statement that catches my original exception:
public void run () {
graphics.setVSync(graphics.config.vSyncEnabled);
try {
LwjglApplication.this.mainLoop();
} catch (Throwable t) {
if (audio != null) audio.dispose();
if (t instanceof RuntimeException)
throw (RuntimeException)t;
else
throw new GdxRuntimeException(t);
}
}
So the debugger stops in the catch statement where the (Gdx)RuntimeException is thrown. I know that t contains the original exception, but I can't really tell where it came from. Is there any way to break at the line that produces that exception?
Untested with libgdx but in similar systems you might be able to do…
try {
foo.run ()
} catch (RuntimeException t) {
System.err.println ("** Caught a runtime exception.");
t.printStackTrace();
Throwable tCause = t;
while (tCause = tCause.getCause()) {
System.err.println("→ caused by:");
t.getCause.printStackTrace ();
}
}
It appears that GdxException.GdxException (Throwable) should call super (t) which in turn should “stash” t in the property for the getCause accessor.
PS: Have you tried running a static analyzer like FindBugs to locate potential NPE's?
How about inspecting the stacktrace and inserting a breakpoint where the NullPointerException is generated?
This is the solution that worked: Add the exception that is shown in t to the list of exceptions that should always trigger the debugger, even when being catched:
Break when exception is thrown
Thanks for the help though :)
I have a design level doubt regarding creating APIs in Java. Suppose I have a class as follows :-
class Test
{
public final static String DEFAULT_ENCODING = "utf-8";
public byte[] encodeIt(String input)
{
try {
return input.getBytes(DEFAULT_ENCODING);
} catch(UnsupportedEncodingException e) {
// do something
}
}
}
I know that the UnsupportedEncodingException would never arise as I'm using a static string as the input to toBytes. It doesn't make sense to have encodeIt do a throws UnsupportedEncodingException because I dont wish the API users to expect and catch that error either.
In such cases, is the best practice to have an empty catch block?
It is a bad idea to have empty catch blocks. Even though your reasoning seems correct this design will at some stage cause you endless debugging and searching once exceptions do start happening and your code is swallowing them. I would wrap your exception in a RuntimeException here and throw that. Like so:
public encodeIt(String input)
{
try {
return input.getBytes(DEFAULT_ENCODING);
catch(UnsupportedEncodingException e) {
throw new RuntimeException(e);
}
}
This way your exception will not stay hidden might it occur nor do your API users have to cater for it.
I do something like this:
public byte[] encodeIt(String input) {
try {
return input.getBytes(DEFAULT_ENCODING);
}
catch (UnsupportedEncodingException e) {
throw new ShouldNeverHappenException(e);
// or: throw new IllegalStateException(e);
}
}
(where ShouldNeverHappenException is a runtime exception, of course).
This way, if someone happens to change the constant value, or add an encoding argument, the method will fail fast and the problem will not go unnoticed or buried in log files.
In such cases, is the best practice to have an empty catch block?
I don't feel that's a good idea, ever. Empty catch blocks mean that something could happen and you'll never know.
Don't throw this exception. Catch it and log it so you can check your assumption that it can never happen, but at least you'll know if never arrives.
I usually follow the strategies outlined by other answers to this question (like soften the checked exception to RuntimeException). However, one interesting alternative is to use an assertion:
public byte[] encodeIt(String input)
{
try {
return input.getBytes(DEFAULT_ENCODING);
} catch(UnsupportedEncodingException e) {
assert false;
return null;
}
}
When assertions are enabled with the -ea JVM flag, this method would throw an AssertionError if ever UnsupportedEncodingException were thrown. An annoyance is the need to return a value (such as null), otherwise the code won't compile.
So perhaps the following is "nicer":
public byte[] encodeIt(String input)
{
try {
return input.getBytes(DEFAULT_ENCODING);
} catch(UnsupportedEncodingException e) {
throw new AssertionError("Unexpected.", e);
}
}
Not so materially different than throwing RuntimeException except that AssertionError is nicely self-documenting. And, being a subclass of Error, it represents a more fundamental failure than Exception normally implies. No chance for a catch (Exception e) clause somewhere higher up on the stack handling this thing (were it to ever occur).
The best way I think is to avoid checked exception. Just use an unchecked one. Then you will take the best of 2 worlds: you do will signal the error if it really happens and you won't force the user of your API to handle the exception.
If you are very, very sure that it would never happen, leave an empty catch block.
But for practice, just in case you change the code later on, it is better to log it to the console when the exception happens.
I am getting an error in NetBeans saying I must throw an SQLException in this method:
private void displayCustomerInfo(java.awt.event.ActionEvent evt)
{
int custID = Integer.parseInt(customerID.getText());
String info = getCustomerInfo(custID);
results.setText(info);
}
This method is created by NetBeans so it is not allowing me to edit the signature and throw the exception. This is why I created the getCustomerInfo() method. This method does throw the exception, because it uses a method to retrieve information from a database about a customer.
public String getCustomerInfo(int cid) throws SQLException
{
Customer c = proc.getCustomer(cid);
// get info
return "info";
}
The getCustomer method also throws the exception and proc.java compiles.
The exact error is
unreported exception java.sql.SQLException; must be caught or declared to be thrown
In general, if your code needs to throw a type of Exception that the signature doesn't support, and you have no control over the interface, you can catch and rethrow as a type the interface does support. If your interface doesn't declare ANY checked exceptions, you can always throw a RuntimeException:
private void displayCustomerInfo(java.awt.event.ActionEven evt)
{
try
{
int custID = Integer.parseInt(customerID.getText());
String info = getCustomerInfo(custID);
results.setText(info);
}
catch (SQLException ex)
{
throw new RuntimeException(ex); // maybe create a new exception type?
}
}
You almost definitely want to create a new Exception type that extends RuntimeException, and have your client code catch that exception. Otherwise, you run the risk of catching ANY RuntimeException, including NullPointerException, ArrayIndexOutOfBoundsException, etc., which your client code probably can't handle.
Read the error message again, it gives you two choices.
You must either declare the exception as thrown (which you cannot do) or catch the exception. Try the 2nd choice.
You need to put a try/catch block around your call to getCustomerInfo(), like so:
private void displayCustomerInfo(java.awt.event.ActionEvent evt)
{
int custID = Integer.parseInt(customerID.getText());
try {
String info = getCustomerInfo(custID);
} catch (SQLException sqle) {
// Do something with the exception
}
results.setText(info);
}
A couple good options for handling the exception might be: logging the exception and the details used to get it, or using it as a signal to retry the connection request. Alternatively, as Outlaw Programmer shows, you could re-throw the Exception as a RuntimeException of some kind, which removes the requirement of checking.
It does not say you must throw it. It says you can catch it. So use a try/catch block and handle it.
try {
...
}
catch (SQLException e) {
System.out.println("Exception happened! Abort! Abort!");
e.printMessage(); //Not sure if this is the correct method name
}
NetBeans generated components have un-modifiable code, and I'm guessing that it is generated as a part of the gui builder. I'd ask if this was the case, but I can't comment yet. If you select a generated object in the GUI editor, on the right there is a tab "code" that can be used to modify the grayed out area of the code.
Here:
I've come across this problem... been puzzled for the past 2 days.. then I open the source (.java file) with sublime, change the code, save, and it works wonders... I'm laughing when I see this works... think outside the box really works...