Sep 30

Maybe the one or the other is asking, how the compiler knows which exceptions it has to take; it is quite easy: With exclusion of RuntimeExeption they have to be declared.

Let’s declare a non-runtime exception on our own:

class Angestellter {

int PersNr;

void setPersNr(int PersNr) throws IOException { // declaration that this methods might throw an exception

if (PersNr > 1000)

throw new IOException();// throwing an exception

else

this.PersNr=PersNr;

}

public static void main(String args[]) {


Angestellter a = new Angestellter();

try { // compulsory try-block; to leave it out leads to CompilerError

a.setPersNr(1001) ;

} catch (IOException e){ e.printStackTrace(); } //catch of error and output of error messages


}

}

Tagged with:
Sep 28

Today I would like to go a little bit deeper in exception-hierarchies:

alternativer TextAbove all exceptions is class Throwable which is (as all other classes) as subclass from Object.

Exceptions/ errors can not be handled during runtime (eg OutofMemoryError) and lead directly to abort of program.

Exceptions are threatable problems, eg. can (in opposite to errors) with a catched NullPointer the programm smoothly continued.

RuntimeExeptionis the baseclass for all exceptions which occur during runtime. They are originated by programmer-mistakes. From this class more differentiated exceptions (eg NullPointerException, ArithmeticException, …) are derivated.

Another from class Exception derivated class is e.g. java.io.IOException and their derivated classes (eg java.io.FileNotFoundException) which are used while working with files.

An implementation of hierarchies can look in the following way:

try { …. }
catch (ArithmeticException e){ … } // catches ArithmeticExeptions
catch (NullPointerException e) { … } // catches NullPointerExceptions
catch (RuntimeException e) { … } // catches RunTimeExeptions
catch (Exception e){ … } // catches all Exceptions

The order need to be always in reverse order to hierarchy, a class Exception everything catches and then the other catch-blocks would be not regarded and therefore obsolete. The compiler recognizes this and returns an Compiler Error.

Basically it is not advisable to catch all Exceptions with catch (Exception e) { } since also unpredictable exceptions could occur which the programmer (and therefore also the programm) can not take into consideration.

Tagged with:
Sep 26

Exceptions are always a subclass of java.lang.Exception. In the last examples I ofte wrote

catch (Exception e) { … } or catch (ArithmeticException e){ … }

Today, I want to explain the content between the brackets:

Exceptions are always a subclass of java.lang.Exception. In this case e is an instance of class Exception, respectively is ArithmeticException in case their exception is catched.

Their methods can be called in the same way as every other class. A very common method is printStackTrace(), which is printing the error-output (which is otherwise only printed in case exception is not catched) in a very controlled way.

Very important in this context is also, that empty curly brackets are allowed, but quite useless:

catch (Exception e) { }

is catching the appropriate error, but does nothing with it. Without e.printStackTrace or other informations/ measueres the error is hidden and not visible or threated at all.

Tagged with:
Sep 24

In case a method which is called from another method the exception will be passed through the main programm.

class Angestellter {

static void test() { test2(); }

static void test2 () { test3(); }

static void test3 () { int i = 1/0; }

public static void main(String args[]) {

test();
}

}

the method-call is ass follows:

main -> test() -> test2() -> test 3; exception is thrown in in method test3. Since the exception is not catched this leads to an programm-abortion. Every method informs its calling method about the occured exception.

The output is similar to:

Exception in thread “main” java.lang.ArithmeticException: / by zero
at Angestellter.test3(Angestellter.java:15)
at Angestellter.test2(Angestellter.java:13)
at Angestellter.test(Angestellter.java:11)
at Angestellter.main(Angestellter.java:18)

Hence, on the order of output it is transparent from where (malfunction first) to where (final point last) the error occured and transferd. The method call is therefore shown in reverse order.

Tagged with:
Sep 22

Shortly an comprehension about the different blocks:

  • try- block: everything which should or even has to be catched (e.g. at some java-methods jvm forces you to use it) will be enclosed in this block
  • catch-block: catching all or only some predefined exceptions
  • finally-block: is mostly used to “clean up” – means to define statetements which should run in any case, no matter if an exception is catched or not.

I am moving forward with some specials:

A try-block has to be finished either with catch or finally.

try { … }

is leading therefore to an CompilerError, allowed is:

try { … } catch (Exception) { … }

try { … } finally { … }

try { … } catch (Exception) { … } finally { … }

no additional code is allowed to be inserted between these blocks:

try { }
System.out.println(“DoSomething”);
// CompilerError
catch (Exception e) { … }

Tagged with:
Sep 20

finally is always called, even in case return is used.

class Angestellter {

static void test() {

File datei = new File(“Test.txt”);

try {

int [] a = new int [4];
a[3]=1;
return;
// return to main programm

}catch (Exception e){

System.out.println(“Exception catched”);

}

finally { // is even called at/ before return

System.out.println(“in finally”);

}

System.out.println(“after Finally”);

}

public static void main(String args[]) {


System.out.println(“call method” );
test();
System.out.println(“after method”);


}


}

The output is here:

call method
in finally
after method

So in any case before leaving the method (no matter if an exception occured or not) finally is always called.

In case an exception is thrown, the output changes to:

call method
Exception catched
in finally
after Finally
after method

reason for the changed output is (beside the exception) that try/catch-block is after throwing the exception no longer excecuted. This means in our example return is not read anymore and therefore not executed.

Tagged with:
Sep 18

finally will be (if declared) always called, no matter if an exception is thrown or not.

Let’s start with an example of thrown exception:

try {

int [] a = new int [3];
a[3]=1;

}catch (Exception e){ System.out.println(“Exception catched”);}

finally { System.out.println(“in finally”);}

System.out.println(“after finally”);

In this case an exception due to the access to the non existing index 3 of the array is thrown.

Therefore the output is:

Exception catched
in finally
after finally

after change of code in order that no exception will be thrown

try {

int [] a = new int [4];
a[3]=1;

}catch (Exception e){

System.out.println(“Exception catched”);

}
finally {

System.out.println(“in finally”);

}
System.out.println(“after finally”);

the output is

in finally
after finally

Tagged with:
Sep 16

With catch exceptions are catched.

On our last excample we just catch with

catch (Exception e){ }

all exceptions, but maybe it should distinguished between different exceptions which could occur?  In this case also multiple exceptions could be catch, simply with several catch-blocks:

File datei = new File(“Test.txt”);

try {

datei.createNewFile(); // one of the java-methods, which have to be obligatory in a try/catch-block

}catch (RuntimeException e) { } // RuntimeException will be catched
catch (IOException e){ } // IOException will be catched
catch (Exception e){ } //all other exceptions will be catched

In case on exception occurs, this one throws a special kind of exception which can be catched explicitely in catch-block. Is one of the catch-blocks able to catch the exception, the other ones will be disregarded.

More about the different kind of exceptions the next days.

Tagged with:
Sep 15

… and now it is called eg Oracle certified Professional, Java SE 5 Programmer for former SCJP Version 1.5. Here you find full overview which java certification is renamed to what. So far no changes in certification itself (beside naming) is announced.

Sep 14

Unfortunately every programmer has sooner or later runtime-exceptions which stop the usual flow. Furthermore, own methods of jvm can fail (eg FileReader in case there is no file). In order being able to handle them and to avoid a crash, huge parts of java standard library are using exception handling.

All critical areas (or those which might be seen as eventually critical) are enclosed by a try/catch-block, the original code remains unchanged:

try {
// code, which eventually exceptions should be catched
}catch (Exception e) {
//instructions for exception handling }

// from here eventually occuring exceptions are not catched anymore

Tagged with:
preload preload preload
http://www.wikio.de Blog Top Liste - by TopBlogs.de Blogverzeichnis - Blog Verzeichnis bloggerei.de Bloggeramt.de Software
Webbhotell Top Blogs