Question:
ok java question about exceptions?
Jalen
2012-10-30 11:09:54 UTC
what is an exception in java? like please give me a great understandable answer. what is the code keywords that go for an exception? what do they do? and could you please give me some examples? sorry ive been having alot of trouble on this part of java.
Five answers:
Jon T
2012-10-30 11:55:22 UTC
Think of it as an error. "Your program would have worked except for this error".



An Exception is used by programmers to ensure everything runs smoothly. There are two types of exceptions, a compile-time exception and a run-time exception.



The run time exceptions are classes that extend java.lang.RuntimeException. They do not prevent your code from compiling and running, but rather get thrown if some sort of input is incorrect that can only be found once the program is running. An example of this is an IndexOutOfBoundsException or a NullPointerException.



public void ioobException() {

. . String[] strings = {"zero", "one", "two"};

. . ioobExample(strings);

}



public void ioobExample(String[] strings) {

. . strings[3]; // throws IndexOutOfBoundsExceptions since there is no index 3

}



public void npException() {

. . npeExample(null);

}



public void npeExample(Object value) {

. . value.toString(); // throws NullPointerException because null was passed in

}



Both of those can only be determined at run time, not when the code is written or compiled.



The compile time exceptions prevent your code from even running if you do not handle them correctly. These extend java.lang.Exception or java.lang.Throwable. Typically they are called hard exceptions as you have to put in logic to handle the case that the exception occurs.



The way you do this is

try {

. . // code that can throw the exception

} catch (YourException e) {

. . // code for what you are going to do to mitigate

}



The other option is to add "throws YourException" to your method signature.



Two tips:

1) You should never get a NullPointerException or an IndexOutOfBoundsException. Those are signs you didn't do proper logical handling.

2) Never "swallow" or "absorb" an exception. This means you don't do a try/catch with an empty catch block. An exception should always be handled in a way that provides input as to what was wrong and recovery opperations

3) Never use a try/catch to control the flow of a program. In other words. Do not do:



public boolean isNumber(String numberString) {

. . try {

. . . . Integer.parseInt(numberString);

. . . . return true;

. . catch (NumberFormatException e) {

. . . . return false;

. . }

}



In this case it is better to use a RegEx to determine if the string is a number.
Akim
2012-10-30 11:31:12 UTC
An exception is actually a kind of error in Java which appears when something goes wrong. A really well known exception is the "NullPointerException". As the name suggests, whenever you try to use a variable which is not initialized (has an initial value of "null") this exception will be thrown. A very simple example would be this:



Object o = null;



System.out.println(o.toString());



This code will give you a NullPointerException since you're trying to get information out of the Object o even though it doesn't have a value yet (the "null" keyword means that it isn't pointing to any memory space). This problem is solved by initializing the object.:



Object o = new Object();



Now this is a very basic example which you will rarely meet in real life, but it's crucial to understand.



In some cases the exceptions which are "thrown" (when an exception occurs we say that the exception is "thrown") it is crucial to "catch" this exception, which means we take the part of the code which may throw an exception, and wrap it in a try-catch statement. This is done like this:



try {

Thread.sleep(1000);

} catch (InterruptedException e)(

//Execute whatever you want when the exception happens

}



The above code will sleep (i.e. pause) for 1 second. The reason we catch an exception, other than the fact that most compilers will force you to, is that Threads are very important things in (Java) programming. Imagine if your thread is interrupted for some reason. Do you want the program to just give you some error and crash on you? No, in most cases you want to be able to control what happens when a Thread malfunctions. That's why exceptions can be very handy.



A lot of the time the compiler will let you execute any code normally, but in some cases (for instance working with Streams, Threads, HttpClients, Urls, etc) the IDE/compiler will ask you to catch these exceptions as safety precautions, just in case something bad happens. That way you can manipulate the error the way you want.



Hope that helped.



Good luck.
TheMadProfessor
2012-10-30 11:58:35 UTC
An exception is any unusual situation encountered at run time that prevents an operation from executing normally. The 'catch' block of code is executed when the exception is detected, but what that code should consist of completely depends on the application. While an exception may indicate an actual error, it isn't necessarily one. For example, you might be trying to open a file that doesn't exist...depending on the application, that might mean you can't continue at all or it might simply mean you need to create the file. All the exception is basically saying is "I can't do what you told me to do because of this." It then looks for an appropriate catch block to tell it what you want to do instead. If no appropriate catch block is found (an 'unhandled exception'), the program comes to a screeching halt.
2012-10-30 11:28:18 UTC
An exception is an error, most simply. If you know there might be an error, like when reading a file that may or may not exist, surround it with a try/catch. Ex:

try {

File f = new File("C:/gamelogs/log1.txt");

}



catch (IOException e) {

System.out.println("IOException: Cannot find file");

}



Or you can define your own and throw them when something happens. First make a class extending Exception (Or any subclass of such) and do:



throw new MyException();





Hope this helps.
brandais
2016-12-28 15:07:22 UTC
it somewhat is authentic. religious music does tend to be horribly, horribly bland. It lacks sincerity and - tho' I hate to apply the be conscious - soul. besides the incontrovertible fact that it on no account was once that way. religious music was once large - Bach's B minor Mass, Mozart's Requiem to illustrate. marvelous, marvelous music created by using people who had to make the suited music they could. those days, the concentration isn't on music yet on "bringing human beings to the Lord". This reduces it to the point of merchandising and propaganda. the extensive-unfold of the music suffers. It sounds like it got here from a "a thank you to compose music" textbook somewhat than from an certainly, unsuitable, susceptible man or woman, that's what music needs to have any genuine cost in any respect.


This content was originally posted on Y! Answers, a Q&A website that shut down in 2021.
Loading...