tags:

views:

203

answers:

6
  1. What is java exception?

  2. Is an exception considered an error?

  3. When should I throw exceptions?

  4. How many kind of exceptions?

+7  A: 

You can start here:

http://java.sun.com/docs/books/tutorial/essential/exceptions/

Marcus L
You are not helpful,on contrary, anyhow accuse querstioner, how mature you are!!
Stupid_medankia
I'm sorry, but it's not my fault you're too lazy to read the manual.
Marcus L
+9  A: 
  1. A signal that something failed in the code, but which is programmatically recoverable.

  2. Depends on how you interprets "error". This is ambiguous.

  3. When you want to signal that something failed in the code, but which is programmatically recoverable.

  4. Countless. You can namely also create custom ones.

To learn more about exceptions, check the Sun tutorial on the subject.

BalusC
+2  A: 
  1. An exception is a recoverable error within your application.

  2. It's relative to what you're doing and what the user expects. Let's say you have a divide by 0 exception, and your application is an calculator. Most users would expect that a message would pop up explaining that they divided by 0.

  3. You should throw exceptions whenever you want. You can make an application that does nothing be throw exceptions. Like an awesome word processor that throws exceptions everytime you hit a key, but when it catches the exception, it output the character you just typed. Also, you can make an awesome game of connect four, where everytime you win it throws an exception.

  4. There are many types of exceptions. A user generated exception (done by the "throw" command), a system exception (example of divide by 0), etc, etc.

Daniel
I should also add that an exception is not necessarily an error, so you shouldn't assume that an exception is a "bad" thing all the time.
Daniel
+4  A: 

What is java exception?

It is a class used to identify unexpected behavior in your application.

Is an exception considered an error?

No always ( and depends on what you call an error )

When should I throw exceptions?

When your application comes into an unexpected state or yo want to signal an unexpected behaviour

How many kind of exceptions?

There are three:

  • Checked exceptions ( have to be handled i.e. FileNotFoundException )

These exceptions are not imputable to the programmer, but to the environment it runs into and the programmer can do something about it ( the programmer can handle it )

  • Runtime exceptions ( a.k.a. GoodProgrammerExpectedtm, should not be handled, i.e. NullPointerException )

These exceptions are programmer faults and originated by bad coding practice ( or knowledge ) and can always be prevented, ie not checking the arrays bounds.

  • Errors ( i.e. OutOfMemoryError, should not be handled )

These exceptions are not imputable to the programmer, but to the environment it runs into, they differ from the checked exception in the fact, the programmer can't do anything about it. For instance, if the system runs out of memory,

See this answer for a more detailed explanation.

OscarRyz
+1  A: 

By the way, you can also create your own Exceptions... for example:

coder's revenge

Cristian
A: 

A Java exception is a mechanism for interrupting the normal program flow, usually -- though not necessarily -- when there is an error that prevents continued processing. Exceptions are most useful for "panic abort eject!!" conditions.

Often when writing a program you come across some condition where it is impossible to proceed. There are often many such conditions possible in a program. For example, suppose you are reading a file that is supposed to contain a list of names and addresses. You may discover that you cannot find the file on the hard drive. THe format may not match what you are expecting. There may be duplicate entries. Etc. Some of these errors may make it impossible to proceed with the operation at all, like "file not found". In other cases you may have to give up on a record but can continue processing the remaining records in the file.

Before exceptions were invented, programmers often found themselves with deeply nested IFs for all the possible errors. Like (some pseudo-code, no particular language):

fileHandle=open("myfile.txt");
if (fileHandle==null)
{
  writeMessage("File not found");
}
else
{
  while (record=fileHandle.read())
  {
    parseRecord(record);
    if (parseError)
    {
      writeMessage("Invalid record format");
    }
    else
    {
      lookupRecord(record);
      if (found)
      {
        writeMessage("Duplicate record");
      }
      else
      {
        ... etc ...
      }
    }
  }
}

This could get very confusing as the number of error conditions grows. Exceptions let us bail out at any point without needing a bunch of "else" clauses.

Also, we often have functions that call other functions that call other functions, etc, or loops within loop within loops. Some errors can be handled deep inside the structure. Mainly this means the ones that we can deal with and recover from, like a bad record. Others should be handled at a higher level. Mainly this means the ones where all we can do is abort the process and display an error message for the user or write the error to a log file or whatever. Exceptions let us do this by setting a level at which we catch the error. We can put the "catch" block immediately after the statement that could create the error and take some corrective action. We can put it a little higher to abort processing of, say, a record, but continue on with the next record. Or we can put it at the top to abort the whole thing. To take the above example:

try
{
  fileHandle=open("myfile.txt");
  if (fileHandle==null)
    throw new FileException("File not found")
while (record=fileHandle.read())
{
  try
  {
    parseRecord(record);
    if (parseError)
      throw new RecordException("Invalid format")
    lookupRecord(record);
      throw new RecordException("Duplicate record")
    ... etc ...
  }
  catch (RecordException e)
  {
    showMessage(e.getMessage())
  }
}
catch (FileException e)
{
  showMessage(e.getMessage())
}

Note that a RecordException will abort processing the record but let us go on to the next. A FileException shoots down the whole thing.

A third advantage of exceptions is that they help to clearly identify the exception conditions.

Well, that's as much of a tutorial as I'm going to write off the top of my head!

Jay