Difference between throw and throws keywords

admin — Sat, 19 May 2012 04:23:31 +0000

Whenever we want to force an exception then we use throw keyword. the throw keyword (note the singular form) is used to force an exception. It can also pass a custom message to your exception handling module. Moreover throw keyword can also be used to pass a custom message to the exception handling module i.e. the message which we want to be printed.

Throw is used to actually throw the exception, whereas throws is declarative for the method. They are not interchangeable.

Throws: this is to be used when you are not using the try catch statement in your code but you know that this particular class is capable of throwing so and so exception(only checked exceptions). In this you do not use try catch block but write using the throw clause at appropriate point in you code and the exception is thrown to caller of the method and is handeled by it

public void myMethod(int param) throws MyException 
{

    if (param < 10)

        throw new MyException("Too low!);

    //Blah, Blah, Blah...

The Throw clause can be used in any part of code where you feel a specific exception needs to be thrown to the calling method.

If a method is throwing an exception, it should either be surrounded by a try catch block to catch it or that method should have the throws clause in its signature. Without the throws clause in the signature the Java compiler does not know what to do with the exception. The throws clause tells the compiler that this particular exception would be handled by the calling method.

Incoming search terms:

How to throw Exceptions in Java

admin — Sat, 19 May 2012 04:18:01 +0000

The exception is an exception object containing the details of the error being raised. This can be declared as an object and initialised before the throw command or included in the throw statement, using the new keyword and one of the exception’s constructors to set the object’s properties.

Before you can catch an exception, some code somewhere must throw one. Any code can throw an exception: your code, code from a package written by someone else such as the packages that come with the Java platform, or the Java runtime environment. Regardless of what throws the exception, it’s always thrown with the throw statement.

Java platform provides numerous exception classes. All the classes are descendants of the Throwable class, and all allow programs to differentiate among the various types of exceptions that can occur during the execution of a program.You can also create your own exception classes to represent problems that can occur within the classes you write.

The throw Statement

All methods use the throw statement to throw an exception. The throw statement requires a single argument: a throwable object. Throwable objects are instances of any subclass of the Throwable class. Here’s an example of a throw statement.

Code: Java

throw someThrowableObject;

If you want to throw an exception explicitly then you need to use the throw clause. All the system-defined exceptions are thrown automatically, but the user-defined exceptions must be thrown explicitly using the throw clause. It takes the form as:

Code: Java

try
 {// statements
 throw new UserDefinedException( );
 // statements
 }catch (UserDefinedException e)
 {
 System.out.printIn (“User defined exception caught”);
 }

The UserDefinedException is a class made specifically to handle an exception and it is encapsulating some specific kind of user defined behaviour. This exception is raised explicitly using the throw clause. At the same time the catch clause is there ready to catch the same exception object.

Consider the following example in which a system defined exception is deliberately thrown in order to demonstrate the functionality of the throw clause:

Code: Java

class Throw_clause {
    public static void main (String args [ ])
    {
        try{
            throw new NullPointerException ( );
        } catch (NullPointerException e){
            System.out.println ("Invalid reference use");
        }
    }
}

Output:

Code:

Invalid reference use

In the above example the throw clause throws an object of a system defined exception NullPointerException, which is actually thrown when an object storing a null pointer is reference. Thus, as soon as an the exception is raised it is caught with the catch clause, the statement inside the catch clause are executed and we get the above output.

Incoming search terms:

How to Use Finally Clause

admin — Sat, 19 May 2012 04:05:43 +0000

The finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. But finally is useful for more than just exception handling — it allows the programmer to avoid having cleanup code accidentally bypassed by a return, continue, or break. Putting cleanup code in a finally block is always a good practice, even when no exceptions are anticipated.
A finally clause is usually included to make sure that some clean-up (e.g., closing opened files) is done.

A finally clause always executes when its try block executes (whether or not there is an exception). Furthermore, if the finally clause includes a transfer of control statement (return, break, continue, throw) then that statement overrides any transfer of control initiated in the try or in a catch clause. First, let’s assume that the finallyclause does not include any transfer of control. Here are the situations that can arise:
1. No exception occurs during execution of the try, and no transfer of control is executed in the try.
  // The finally clause executes, then the statement following the try block.
2. No exception occurs during execution of the try, but it does execute a transfer of control.
  // The finally clause executes, then the transfer of control takes place.
3. An exception does occur during execution of the try, and there is no catch clause for that exception.
  // The finally clause executes, then the uncaught exception is “passed up” to the next enclosing try block, possibly in a calling function.
4. An exception does occur during execution of the try, and there is a catch clause for that exception. The catch clause does not execute a transfer of control.
  // The catch clause executes, then the finally clause, then the statement following the try block.
5. An exception does occur during execution of the try, there is a catch clause for that exception, and the catch clause does execute a transfer of control.
  // The catch clause executes, then the finally clause, then the transfer of control takes place.
If the finally block does include a transfer of control, then that takes precedence over any transfer of control executed in the try or in an executed catch clause. So for all of the cases listed above, the finally clause would execute, then its transfer of control would take place. Here’s one example:
```
    try {
        return 0;
    } finally {
        return 2;
    }
```
The result of executing this code is that 2 is returned.Note that this is rather confusing! The moral is that you probably do not want to include transfer-of-control statements in both the try statements and the finally clause, or in both a catch clause and the finally clause.

Try-finally clauses in bytecodes

In bytecodes, finally clauses act as miniature subroutines within a method. At each exit point inside a try block and its associated catch clauses, the miniature subroutine that corresponds to the finally clause is called. After the finally clause completes — as long as it completes by executing past the last statement in the finally clause, not by throwing an exception or executing a return, continue, or break — the miniature subroutine itself returns. Execution continues just past the point where the miniature subroutine was called in the first place, so the try block can be exited in the appropriate manner.

How to Catch Exceptions

admin — Sat, 19 May 2012 03:59:49 +0000

To see how an exception is caught, you must first understand the concept of a guarded region. This section of code might produce exceptions and is followed by the code to handle those exceptions.

If you are inside a method and you throw an exception (or another method that you call within this method throws an exception), that method will exit in the process of throwing. If you don’t want a throw to exit the method, you can set up a special block within that method to capture the exception. This is called the try block because you “try” your various method calls there. The try block is an ordinary scope preceded by the keyword try.

Catch exceptions using try blocks:

    try {
       // statements that might cause exceptions
       // possibly including function calls
    } catch ( exception-1 id-1 ) {
       // statements to handle this exception
    } catch ( exception-2 id-2 ) {
       // statements to handle this exception
    .
    .
    .
    } finally {
       // statements to execute every time this try block executes
    }

Notes:

Each catch clause specifies the type of one exception, and provides a name for it (similar to the way a function header specifies the type and name of a parameter). Java exceptions are objects, so the statements in a catch clause can refer to the thrown exception object using the specified name.
The finally clause is optional.
In general, there can be one or more catch clauses. If there is a finally clause, there can be zero catch clauses.

Example (a program that tries to open a file named by the first command-line argument for reading)

public static void main(String[] args)
{
    InputStream istream;
    File        inputFile;

    try {
        inputFile = new File(args[0]);
	istream =   new InputStream(inputFile);  // may throw FileNotFoundException
    } catch (FileNotFoundException ex) {
        System.out.println("file " + args[0] + " not found");
    }
}

Notes:

The program really should make sure there is a command-line argument before attempting to use args[0].
Also, it probably makes more sense to put the try block in a loop, so that if the file is not found the user can be asked to enter a new file name, and a new attempt to open the file can be made.
As is, if the user runs the program with a bad file name foo, the message “file foo not found” will be printed, and the program will halt.
If there were no try block and the program were run with a bad file name foo, a more complicated message, something like this:
```
	 java.io.FilenotFoundException: foo
	    at java.io.FileInputStream ...
	    at ...
	    at Test.main ...
```
would be printed. (Actually, if there were no try/catch for the FileNotFoundException, the program wouldn’t compile because it fails to list that exception as one that might be thrown. We’ll come back to that issue later…)

Incoming search terms:

Java Null pointer exceptions

admin — Sat, 19 May 2012 03:50:16 +0000

NullPointerException is the exception that occurred when a programmer perform an operation on a object or calling a method on the object i.e null. This exception is thrown by JVM.We should not handle that exception by try and catch block The only way to resolve Null Pointer Exception is to avoid performing the operation on an object or method of the object i.e is null.

Of the things which can go wrong at runtime in Java programs, null pointer exceptions are by far the most common. Recall that all values in Java programs are either scalars or references to objects, and that all variables have default values, which in the case of object references is null. Object references are like pointers in C, but are much more constrained: a C pointer can point to an arbitrary store location, while a Java object reference can point to an object of known type, or be null. When making a method call:

x.m()

there are therefore only two things that can go wrong: x might refer to a different object to that we intended, or it could be null. Fortunately, the latter is much more common in practice. The procedure for debugging null pointer exceptions is very simple:

Identify the line where it occurred.
Ask “what objects (or arrays) are being referenced on this line”. One of them is null and it’s usually obvious which.
Figure out why it’s null.

Usually the thing which is null is an instance variable, and it’s null because of some cockup with the constructor. This can occur in many ways: I’ve seen all of the cases below occur in practice, most of them many times. Suppose we have a simple class:

public class Widget {
private int value;

public Widget(int v) { value = v; }

public int getValue() { return value; }
}

and another class which uses it:

public class Oops {

private Widget theWidget;

public static void main(String[] args) {
Oops myInstance = new Oops();
System.out.println(myInstance.theWidget.getValue());
}
}

Obviously, when we run this we get a nullPointerException (1), because theWidget has its default value of null, courtesy of the default constructor for class Oops. (In principle, there are four things on the line which could be null – four dots – but we can hopefully rule out System and System.out, and we just created myInstance, so it has to be theWidget).

So we need to provide an appropriate constructor, which will either take a Widget as a parameter, or create one. In the former case, we ought to use a meaningful name for the parameter, and it’s tedious to keep inventing meaningful names, so let’s use the same name as the instance variable:

public Oops(Widget theWidget) {
theWidget = theWidget;
}

nullPointerException (2). Oh, of course, we forgot to change the main program, the default constructor’s still getting called.

...
Oops myInstance = new Oops(new Widget(42));
...

NullPointerException (3) Eh? The problem is that both sides of the assignement

theWidget = theWidget;

refer to the parameter, not to the instance variable, which isn’t touched. One solution – actually the one I use, is to explicitly say 'this.' on the left hand side. I used to think this was completely safe, but:

public Oops(Widget theWiget) {
this.theWidget = theWidget;
}

nullPointerException (4) Que? This time, because of the mis-spelling of the parameter name, both sides of the assignment refer to the instance variable, and it still doesn’t get set properly.

Possibly the safest way is to use the same names, but decorate one or the other by some systematic convention like a leading underscore. (I think it’s better to decorate the parameter, because that will probably only be referred to once, but some people prefer to decorate instance variables.)

public Oops(Widget _theWidget) {
this.theWidget = _theWidget;
}

The this. is now redundant, but I find it clearer to leave it in. The only thing which can go wrong now is if the parameter is null:

...
Oops myInstance = new Oops(null);
...

nullPointerException (5). In general, the caller of a constructor (or a method in general) is responsible for providing sensible parameters, and you shouldn’t assume null is ok unless the documentation explicitly says so.

Now suppose we create the widget in the constructor:

public Oops() {
Widget theWidget = new Widget(42);
}
...
Oops myInstance = new Oops();
...

nullPointerException (6). This time, the left hand side of the assignement is a local variable in the constructor, and again the instance variable isn’t touched.

Finally, my favourite:

public void Oops() {
this.theWidget = new Widget(42);
}
...
Oops myInstance = new Oops();
...

nullPointerException (7).

The problem is that the keyword void has slipped in, as a result of which we don’t have a constructor at all, but a method which happens to have the same name as the class! This is legal, although obviously not a good idea. The call to new Oops() therefore calls the default constructor again and we know the rest.

If void is omitted, this version works:

public  Oops() {
this.theWidget = new Widget(42);
}
...
Oops myInstance = new Oops();
...

These all look like pretty dumb mistakes when presented this way, but remember that normally there’s a lot of other code around to confuse the issue.

When you see a null pointer exception. You should go to the line specified in the error and check if there might be any null references there. To do that you can add basic “if statements” for your object references used around that line (just like goldhouse did for f variable in the above code.). Once you found the null reference variable, you can fix the problem by changing the code there. This step is application specific: you might need to make sure that no null reference is there or you can allow null references but control the program flow for not getting a null pointer exception.

Incoming search terms:

C# Versus Other Programming Languages

admin — Sun, 30 Oct 2011 05:54:41 +0000

C# is one of the newest programming languages. It is a good that this will become a very popular language for a number of reasons. One of the key reasons is Microsoft and the promises of .NET.

You might have heard about Visual Basic, C++, and Java. Perhaps you’re wondering what the differences are between C# and these other programming languages. You might also be wondering whether you should be teaching yourself one of these three languages instead of C#.

Microsoft says that C# brings the power of C++ with the ease of Visual Basic. C# does bring a lot of power, but is it as easy as Visual Basic? It might not be as easy as Visual Basic 6, but it is as easy as Visual Basic .NET (version 7), which was rewritten from the ground up. The end result is that Visual Basic is really no easier than programming C#. In fact, you can actually write many programs with less code using C#.

C# was meant to be an advance over both C++ and Java as a general purpose programming language. Although it can be argued that some of its features are a step backward, C# clearly includes some constructs that move it beyond its predecessors. Some of its features will surely be adopted by programming languages of the near-term future.

Although C# removes some of the features of C++ that cause programmers a lot of grief, no power or functionality was really lost. Some of the programming errors that are easy to create in C++ can be totally avoided in C#. This can save you hours or even days in finishing your programs. You’ll understand more about the differences from C++ as you learn C#.

You might also have heard of the C programming language. Many people wonder if they should learn C before learning C#, C++, or Java. Simply put, there is absolutely no need to learn C first.

Another language that has gotten lots of attention is Java. Java, like C++ and C#, is based on C. If you decide to learn Java later, you will find that a lot of what you learn about C# can be applied.

Incoming search terms:

Differences Between C# and C++

admin — Sat, 29 Oct 2011 10:22:44 +0000

C# is a modern object-oriented language developed by a Microsoft team led by Anders Hejlsberg. C# is a strongly typed object-oriented language whose code visually resembles C++ (and Java). This decision by the C# language designers allows C++ developers to easily leverage their knowledge to quickly become productive in C#, C# syntax differs from C++ in some ways, but most of the differences between these languages are semantic and behavioral, stemming from differences in the runtime environments in which they execute.

C# source code compiles into managed code. Managed code, as you may already know, is an intermediate language (IL) because it is halfway between the high-level language (C#) and the lowest-level language (assembly/machine code). The Common Language Runtime, or CLR for short, is the virtual machine on which C# runs. Many languages run on the CLR and this means they can all be compiled and used on Windows PCs, the Xbox 360, and the Zune. The CLR is owned and developed by Microsoft, but there is also an open-source version of the CLR called Mono. Using Mono, C# programs can be run on Macs, Linux, or any other system for which Mono can be compiled. At runtime, the Common Language Runtime(CLR) compiles the code on the fly by using Just In Time (JIT) compiling. As with just about anything in engineering, this technique comes with its pros and cons. It may seem that an obvious con is the inefficiency of compiling the code at runtime. This process is different from interpreting, which is typically used by scripting languages such as Perl and JScript.

The JIT compiler doesn’t compile a function or method each and every time it’s called; it does so only the first time, and when it does, it produces machine code native to the platform on which it’s running. An obvious pro of JIT compiling is that the working set of the application is reduced, because the memory footprint of intermediate code is smaller. During the excetion of the application, only the needed code is JIT-compiled. If your application contains printing code, for example, that code is not needed if the user never prints a document, and therefore the JIT compiler never compiles it. Moreover, the CLR can optimize the program’s execution on the fly at runtime. For example, the CLR may determine a way to reduce page faults in the memory manager by rearranging compiled code in memory, and it could do all this at runtime. Once you weigh all the pros together, you find that they outweigh the cons for most applications.

Unlike C#, C++ code traditionally complies into native code. Native code is the machine code that’s native to the processor for which the program was compiled. For the sake of discussion, assume that we’re talking about natively compiled C++ code rather than managed C++ which can be achieved by using C++/CLI. Compilers take human-readable source code, written in a language like C++ or C, and compile it into machine code. For example, the PlayStation 3 C++ compiler compiles source code into machine code that can run on the Cell CPU. To run the same C++ code on the Xbox 360 Xenon CPU, it must be compiled again using the Xbox 360 C++ complier. C# doesn’t work like this. C# compiles down to an assembly language called the common intermediate language or CIL. CIL is then run on a virtual machine that generates the machine code for the particular system. In the PlayStation 3 case that would mean to run C# on the PlayStation, it would need a virtual machine that could take CIL code and output machine code that the Cell CPU understands. If you want your native C++ application to run on different platforms, such as on both a 32-bit platform and a 64-bit platform, you must compile it separately for each. The native binary output is generally not compatible across platforms.

Incoming search terms:

What Is Pseudocode?

admin — Wed, 26 Oct 2011 16:33:53 +0000

Pseudocode and flowcharts are both popular ways of representing algorithms. Pseudocode has been chosen as the primary method of representing an algorithm because it is easy to read and write, and allows the programmer to concentrate on the logic of the problem. Pseudocode is really structured English. It is English that has been formalised and abbreviated to look like the high-level computer languages.

Pseudocode provides another way to represent program logic. The approach is to write the program in a language similar to the one used for implementation but with an easily understood shorthand for complex expressions. The idea is to represent the logic but to ignore many of the syntactic requirements of the programming language.

A pseudocode design description is thus a mixture of human language and programming constructs. Instead of the complete logic for well-known functions, simple statements are used. Similarly, the program flow can be represent with traditional conditional statements, using written expressions to describe the logic. While there are no generally accepted pseudocode notation standards, it is a good idea to use language constructs that are similar to those in the high-level language being used. When you do, the psedocode will look familiar at implementation time and will provide a framework for implementation.

Because pseudocode does not require the programming language details, it is generally easier and quicker to produce than a completed source program. While there is no standard pseudocode, once you understand one version, it is easy to understand other versions. Many programmers use pseudocode. Abstract versions of it are used to express abstract algorithms. More language specific versions of it are used to express design for programs in those languages. Pseudocodes supposed to be clear enough that a human being can execute it “by hand,” without using a computer and with little or no knowledge of programming languages.

Pseudocode is used to represent the algorithm. The common characteristics of pseudocode :

Statements are written in simple English
Each instructions is written on a separate line
Keywords and indentation are used to signify particular control structures
Each set of instructions is written from top to bottom, with only one entry and one exit
Groups of statements may be formed into modules, and the module given a name

Incoming search terms:

Why Exception Handling Is Handy

admin — Fri, 21 Oct 2011 03:31:35 +0000

For starters, exception handling brings order to the error identification and management process through the use of a generalized strategy for not only identifying and reporting application errors, but also specifying what the program should do once an error is encountered. Furthermore, exception handling syntax promotes the separation of error handlers from the general application logic, resulting in considerably more organized, readable code. Most languages that implement exception handling abstract the process into four steps:

1. The application attempts to perform some task.
2. If the attempt fails, the exception-handling feature throws an exception.
3. The assigned handler catches the exception and performs any necessary tasks.
4. The exception-handling feature cleans up any resources consumed during the attempt.

In a perfect world, your program would run like a well-oiled machine, devoid of both internal and userinitiated errors that disrupt the flow of execution. However, programming, like the real world, often involves unforeseen happenings that disrupt the flow of events. In programmer’s lingo, these unexpected happenings are known as exceptions. Some programming languages have the capability to react gracefully to an exception, a behavior known as exception handling. When an error is detected, the code issues, or throws, an exception. In turn, the error-handling code takes ownership of the exception, or catches it. The advantages to such a strategy are many.

Almost all languages have borrowed from the C++ syntax, known as try/catch. Here’s a simple
pseudocode example:

try { perform some task if something goes wrong throw exception("Something bad happened") // Catch the thrown exception } catch(exception) { output the exception message }

You can also create multiple handler blocks, which allows you to account for a variety of errors. You can accomplish this either by using various predefined handlers or by extending one of the predefined handlers, essentially creating your own custom handler. PHP currently only offers a single handler, exception. However, that handler can be extended if necessary. It’s likely that additional default handlers will be made available in future releases. For the purposes of illustration, let’s build on the previous pseudocode example, using contrived handler classes to manage I/O and division-related errors:

try { perform some task if something goes wrong throw IOexception("Could not open file.") if something else goes wrong throw Numberexception("Division by zero not allowed.") // Catch IOexception } catch(IOexception) { output the IOexception message } // Catch Numberexception } catch(Numberexception) { output the Numberexception message }

If you’re new to exceptions, this standardized approach probably seems like a breath of fresh air. The next section applies these concepts to PHP by introducing and demonstrating the variety of new exception-handling procedures made available in version 5.

Incoming search terms:

Steps in Program Development

admin — Tue, 18 Oct 2011 09:28:27 +0000

Computer programming is an art. Many people believe that a programmer must be good at mathematics, have a memory for figures and technical information, and be prepared to spend many hours sitting at a computer, typing programs. However, given the right tools and steps to follow, anyone can write well designed programs. It is a task worth doing, as it is both stimulating and fullfilling.

Programming can be defined as the development of a solution to and identified problem, and the setting up of a related series of instructions that, when directed through computer hardware, will produce the desired results. It is the first part of this definition that satisfies the programmer’s creative needs; that is, to design a solution to an identified problem. Yet this step is so often overlooked. Leaping straight into the coding phase without first designing a proper solution usually results in a program that contains many errors. Often the programmer then needs to spend a significant amount of time finding these errors and correcting them. A more experienced programmer will design a solution to the program first, desk check this solution, and then code the program in a chosen programming language.

These are seven basic steps in the development of a program, as follows.

1. Define the problem

This step involves carefully reading and rereading the problem until you understand completely what is required. To help with this initial analysis, the problem should be divided into three separate components: the inputs, the outputs, the processing steps to produce the required outputs. A defining diagram is recommended in this analysis phase, as it helps to separate and define the three components.

2. Outline the solution

Once the problem has been defined, you may decide to break it down into smaller tasks or steps, and establish solution outline. This initial outline is usually a rough draft of the solution. The solution outline may also include a hierarchy or structure chart.

3. Develop the outline into an algorithm

The solution outline developed in Step 2 is then expanded into an algorithm: a set of precise steps that describe exactly the tasks to be performed and the order in which they are to be carried out. This book uses pseudocode to represent the solution algorithm.

4. Test the algorithm for correctness

This step is one of the most important in the development of a program and yet it is the step most often bypassed. The main purpose of desk checking the algorithm is to identify major logic errors early, so that they may be easily corrected. Test data needs to be walked through each step in the algorithm to check that the instructions described in the algorithm will actually do what they supposed to.

5. Code the algorithm into a specific programming language

Only after all design considerations in the previous four steps have been met should you actually start to code the program into your chosen programming language.

6. Run program on the computer

This step uses a program compiler and programmer-designed test data to machine test the code for syntax error and logic error. This is usually the most rewarding step in the program development process. This step may need to be performed several times until you are satisfied that the program is running as required.

7. Document and maintain the program

Program documentation should not be listed as the last step in the program development process, as it is really an ongoing task form the initial definition of the problem to the final test result. Documentation includes both external documentation and internal documentation that may have been coded in the program.

Difference between throw and throws keywords

Incoming search terms:

How to throw Exceptions in Java

The throw Statement

Incoming search terms:

How to Use Finally Clause

Try-finally clauses in bytecodes

How to Catch Exceptions

Incoming search terms:

Java Null pointer exceptions

Incoming search terms:

C# Versus Other Programming Languages

Incoming search terms:

Differences Between C# and C++

Incoming search terms:

What Is Pseudocode?

Incoming search terms:

Why Exception Handling Is Handy

Incoming search terms:

Steps in Program Development

Incoming search terms: