Exception handling

[sharathg.satya]

Is exception handling useful in
compile time errors
logical errors
and even runtime errors?

[DavidKroukamp]

Is exception handling useful in
compile time errors
logical errors
and even runtime errors?

Exceptions are only used for runtime errors in code. The compile time errors/ logical errors are thanks to the actual java compiler, as far as i know.

[DJSAN10]

Compile time errors are syntactic errors, they are notified at compile time i.e. before you run your program . Exceptions are run time errors.

Compiler does not recognize them. You know you have encountered an exception only once you execute a program.

[stultuske]

actually, they're usually caused by the programmer writing a lot of 'blablabla' instead of decent java code.

a logical error: well, in most cases (unless you actually validate yourself and throw an exception yourself if your result is not what you expect it to be) will not throw an Exception, since the computer just runs the code the developer wrote, hence, is assumed to be what the developer wants it to do.
just a for instance:

int total = 0;
int number1 = readANumber();
total += number1;
System.out.println("The sum of the two numbers = " + total);
int number2 = readANumber();
total += number2;

easy to spot for the naked eye, but you can't expect your compiler to notice a mistake like this.

a compile time error is thrown while compiling. you can't actually 'handle' one of these in your code, since your code won't run until it has been succesfully compiled.

[sharathg.satya]

ok thanks to all

[sharathg.satya]

ok thanks to all

If i am given a question that...
exception handling is useful to overcome..
a.compiletime error
b.runtime errors.
c.logical errors.
d.all the above.

then what should be my answer..?
we use exception handling for runtime errors and can also be made to handle logical errors.
so what can be the answer.

[stultuske]

it's not useful to overcome logical errors.
it would only be useful in that, if you knew before running the code where you would come into one and what the correct information would be, but if you knew that, you woulnd't have the error. the rest of the answer can be derived from the above answers.

[sharathg.satya]

it's not useful to overcome logical errors.
it would only be useful in that, if you knew before running the code where you would come into one and what the correct information would be, but if you knew that, you woulnd't have the error. the rest of the answer can be derived from the above answers.

well
but if we consider
int a=3,b,c;
and we input the value of b from the user who may think it can be any value
and after few executable statements if we have ....
c=a/b;
and if the value of b is 0 even here we know that we can get a logical error and hence we write the code in the try block..(which indirectly means that we are even using exception handling for logical errors.)
isnt it?

[stultuske]

what you describe is a runtime exception, not a logical error.
true, you can add validation to make sure b will never be 0, or you can add a try catch block, but a real logical value is, for instance, printing the result of a sum, before you added every element up.

if you take a look at my previous post, with the little snippet, you can see that the result is printed before the second number is added. what if this wasn't a result, but a method call which should use the total as parameter? you would have a wrong result somewhere in your code, while you have no idea of knowing.

also, the code would never throw an Exception, it's just a line placed on a wrong place in the code, stupid mistake, but can have grave results.

[DavidKroukamp]

well
but if we consider
int a=3,b,c;
and we input the value of b from the user who may think it can be any value
and after few executable statements if we have ....
c=a/b;
and if the value of b is 0 even here we know that we can get a logical error and hence we write the code in the try block..(which indirectly means that we are even using exception handling for logical errors.)
isnt it?

Three types of errors

There are basically 3 types of errors that you must contend with when writing programs:

Syntax errors
Runtime errors
Logic errors

Generally speaking, the errors become more difficult to find and fix as you move down the list.

Syntax errors:

In effect, syntax errors represent grammar errors in the use of the programming language. examples are:

Misspelled variable and function names
Missing semicolons
Improperly matches parentheses, square brackets, and curly braces
Incorrect format in selection and loop statements

Runtime errors:

Runtime errors occur when a program with no syntax errors asks the computer to do something that the computer is unable to reliably do. Common examples are:

Trying to divide by a variable that contains a value of zero
Trying to open a file that doesn't exist
There is no way for the compiler to know about these kinds of errors when the program is compiled. Only during runtime when an exception which is designed to check for a certain event is thrown or raised.

Logic errors:

Logic errors occur when there is a design flaw in your program. Common examples are:

Multiplying when you should be dividing
Adding when you should be subtracting
Opening and using data from the wrong file
Displaying the wrong message

and this also helps to explain more:
Compile time error is any type of error that prevent a java program compile like a syntax error, a class not found, a bad file name for the defined class, a possible loss of precision when you are mixing different java data types and so on.

A runtime error means an error which happens, while the program is running. To deal with this kind of errors java define Exceptions. Exceptions are objects represents an abnormal condition in the flow of the program. It can be either checked or unchecked.

[stultuske]

as you said in your example this is a logical error...

it's the user using the code in a way it was not intended, and yes, the developer should have foreseen the possibility, but trust me, it's a runtime exception :)

a logical error would happen every time you run the code, not just some times depending on which input is given by the user.

[DavidKroukamp]

it's the user using the code in a way it was not intended, and yes, the developer should have foreseen the possibility, but trust me, it's a runtime exception :)

a logical error would happen every time you run the code, not just some times depending on which input is given by the user.

check edited post, better explanation now

[stultuske]

check edited post, better explanation now

my previous post was still based on the unedited version :)
also: mismatched/placed brackets, .. can be logical errors too ;) :D

[DavidKroukamp]

my previous post was still based on the unedited version :)
also: mismatched/placed brackets, .. can be logical errors too ;) :D

lol yup i know hence why i was editing to get my point across in a more clearer and correct manner

arrrrrrghhhhhhhh!!!!! :) but agreed,and yes yes that is right Mr. Know-it-all Stultuske :D

[sharathg.satya]

lol yup i know hence why i was editing to get my point across in a more clearer and correct manner

arrrrrrghhhhhhhh!!!!! :) but agreed,and yes yes that is right Mr. Know-it-all Stultuske :D

Well thanks for all
i think i got cleared with the question

[dewitt-joyce]

[link removed]

Exception handling is a programming language construct or computer hardware mechanism designed to handle the occurrence of exceptions, special conditions that change the normal flow of program execution.

Programming languages differ considerably in their support for exception handling (as distinct from error checking, which is normal program flow that codes for responses to contingencies such as unsuccessful termination of invoked operations). In some programming languages there are functions which cannot be safely called on invalid input data or functions which return values which cannot be distinguished from exceptions. For example, in C the atoi (ASCII to integer conversion) function may return 0 (zero) for any input that cannot be parsed into a valid value. In such languages, the programmer must either perform error checking (possibly through some auxiliary global variable such as C's errno) or input validation (perhaps using regular expressions) or both.

The degree to which such explicit validation and error checking is necessary is in contrast to exception handling support provided by any given programming environment. Hardware exception handling differs somewhat from the support provided by software tools, but similar concepts and terminology are prevalent.

In general, an exception is handled (resolved) by saving the current state of execution in a predefined place and switching the execution to a specific subroutine known as an exception handler. Depending on the situation, the handler may later resume the execution at the original location using the saved information. For example, a page fault will usually allow the program to be resumed, while a division by zero might not be resolvable transparently.

From the processing point of view, hardware interrupts are similar to resume-able exceptions, though they are typically unrelated to the user's program flow.

From the point of view of the author of a routine, raising an exception is a useful way to signal that a routine could not execute normally - for example, when an input argument is invalid (e.g. a zero denominator in division) or when a resource it relies on is unavailable (like a missing file, or a hard disk error). In systems without exceptions, routines would need to return some special error code. However, this is sometimes complicated by the semipredicate problem, in which users of the routine need to write extra code to distinguish normal return values from erroneous ones.

One mechanism for raising an exception is known as a throw. The exception is said to be thrown. Execution is transferred to a "catch".

In runtime engine environments such as Java or .NET, there exist tools that attach to the runtime engine and every time that an exception of interest occurs, they record debugging information that existed in memory at the time the exception was thrown (call stack and heap values). These tools are called automated exception handling or error interception tools and provide 'root-cause' information for exceptions.

Contemporary applications face many design challenges when considering exception handling strategies. Particularly in modern enterprise level applications, exceptions must often cross process boundaries and machine boundaries. Part of designing a solid exception handling strategy is recognizing when a process has failed to the point where it cannot be economically handled by the software portion of the process.