Unchecked Exception Handling in an Applet

What happens in a multithreaded applet when you get an unchecked exception (Array out of Bounds)?
Where does control pass after the stack trace? Are threads that are not in the exception code path still running?
Yes, I have fixed the out of bounds errors, but I am investigating where subsequent behavior may be the result of the exception or a race condition.

An unhandled Exception terminates execution of the current thread. Other executing threads are not directly effected by the uncaught Exception (and subsequent termination).
Any locks help by the thread should be released once control passes out of the run method (due to the Exception).

Similar Messages

Unchecked exceptions in web services

Hi all.
How are unchecked exceptions handled in web services ? Are they automatically mapped as SOAPFaults in the SOAP return message ?

With JAX-WS and JAX-RPC , yes.

Checked and unchecked exceptions - when to use which ?

Hi,
Example:
public void go(String[] args) {
if(args.length==0)
throw new // <= what type of an exception should come here ?
}Is there a good explanation when to use which one ? I know that generally
unchecked exception are the exceptions associated with errors in the logic
of your applications and checked are those which you can not determine
(like files, networks problems ....).
Thanks,
Adrian

There is no, "I think it is better to us a type-XXX exception here because of conditions 1, 2, and 3" scenario.
Checked exceptions are of type java.lang.Exception and must be handled in one of two ways- try/catch constructs or having the method state it throws the checked exception.
Unchecked exceptions are of type java.lang.Error or java.lang.RuntimeException. If the problem is an Error, something very bad has occurred like running out of memory. If it is a RuntimeError, then it probably came from a program bug. In both cases, there is no way for you to know when they will arise. Therefore the compiler does not force you to handle these unusual circumstances.
If you think of piece of code may throw an error like an I/O operation, and you do not have code to handle that possibility, the compiler will let you know. After you have been programming long enough, you'll begin to know when you need try/catch constructs without Mr. Compiler yelling at you. ;-)
Edited by: filestream on Sep 14, 2007 5:37 PM

Exception handling framework?

Can anyone recommend an exception handling framework or perhaps pattern for Applets?
Thanks, Tom.

Methinks you're gonna be stuck. Unless every catch block already happens to call some central method (or small set of methods) and passes in the exception, there is no way I can think of to "flip a switch" and magically have all your catch blocks start logging messages when they weren't before. You'll probably have to change the code every place you want to log something. This is why it's a great idea to think of those sorts of things before coding a huge application. :-) I'm not criticizing you since it sounds like you inherited this.

JAVA BEANSHELL EXCEPTION HANDLING

Hi
still new to ODI
I have created a java beanshell script in ODI which calls a simple java class, cars, then sets the no of seats to a value designed to raise an exception. Exception raised but procedure works OK,
How can I register the fact that it has failed through exception handling? (It is possible that my java exception handling isn't quite right)
The no of seats has no effect on the success/failure of the ODI procedure, but the log shows that the exception is caught !
any assistance gratefully received.
Regards
Terry
cars class: (added to agent start)
====================
public class cars {
private int seats;
public void setSeats (int seats) throws tooManySeatsException {
if (seats) < 100) {
this .seats = seats;
} else {
throw new tooManySeatsException("Too many seats");
public int getSeats () {
return this.seats;
class tooManySeatsException extends Exception {
public tooManySeatsException (String msg){
super();
Java beanshell procedure in ODI
====================
import cars;
public class carsTest {
public carsTest(){
public void init(){
cars c = new cars();
c.setSeats(20);
//c.setseats(200);
try {
carsTest ct = new carsTest();
ct.init();
} catch (Exception e) {
throw Error (e);
}

Your code throws exception when you set value >100 but you are setting 20 thus it would not throw exception.
In the procedure step you can uncheck "Ignore error" flag to let execution failed on throwing any exception from your code. If you check that flag then the execution would not fail rather lease the task in warning state.

Find all unchecked exceptions thrown by method?

Dear all,
I am writing critical code that must be correct. Thus, I wish to know that I have not overlooked any important unchecked exceptions. I am aware that the distinction between unchecked and checked exceptions is controversial, and I know the difference between these types of exceptions.
I would like to see for each function a list of all possible exceptions a method can throw. Preferably I would like a tool to do this for me, but I would write something myself if there is a reasonably simple way to do it.
More precisely, I would like to be able to define the set of "unchecked" exceptions myself, e.g., I would put down NullPointerException as "unchecked", but I would let IOException be checked (in my particular application, not in general). In general, this would however be a very nice language feature that could perhaps be a compromise in the (un)checked exceptions-controversy. Each programmer could define an "unchecked"-filter. Perhaps it would best be viewed as a kind of lint.
In any case, I have not found any tool, and it seems I can not do it myself with reflection, since it only gives access to declared exceptions, i.e., if the JDK-programmer decided not to put IOException in the signature of a method, then reflection can not see that the method may throw such an exception.
Does anybody know how to do this?

Douglas1024 wrote:
Thank you for your time, but I am well aware how one uses exceptions in normal code.
From an abstract point of view exceptions are simply a form of outputs from a method. Thus, if the goal is to write correct and easily verifiable code, in contrast to the vast majority of code that simply works reasonably, it is quite meaningful to know exactly what kinds of exceptions are thrown by a method and when.
Please note my correction regarding IOException.Millions upon millions of lines of correct code have been written following these standard java exception principles. The notion that you can write "better" code by detailing every single unchecked exception that could possibly be thrown is ludicrous. In fact by handling unchecked exceptions you will in all likelihood do more harm than good, hence why they are unchecked in the first place.

Unchecked exception

hi all...
can throws be used to avoid unchecked exception???
for example,,,,,in this c ode throws is not able to handle unchecked exception i.e. arithmetic exception.....
public class Test {
public static void main(String[] args) throws ArithmeticException{
int a=1,b=0,c;
c=a/b;
System.out.println(c);
but This code is working fine ,,,when i am using try catch to handle this exception
public class test1 {
public static void main(String[] args) {
try{
int a=1,b=0,c;
c=a/b;
System.out.println(c);}
catch(ArithmeticException e)
System.out.println("error occured");
..........................

The throws clause doesn't handle an exception, it warns the caller of the method that there's a checked exception that the code that calls it needs to deal with.
Unchecked exceptions (e.g zero divide) are usually not handled, they typically cause the program to abnormally terminate. That's because, as a general rule, an unchecked exception means there's something wrong with the program so what's the point of continuing?
A checked, exception, on the other hand, usually indicates that there's something wrong with the program's environment. A data file is missing or has the wrong format, the user has entered something other than a number where a number is expected or something of that kind, and it often makes sense for the program to try and recover (e.g. by asking for the data again).

Purpose of throws clause in exception handling

hi all,
I have written a sample code for exception handling...please refer below....
class a
void fun() throws ArithmeticException
int i=0;
i=10/0;
class exec
public static void main(String a[])
a a1=new a();
try{a1.fun();}
catch(ArithmeticException e){System.out.println("hi");}
}

I read the article...and came out with these points...
1..If method is throwing an unchecked exception (as in this case) then there is no need for throws clause, if you are not catching it then and there only.....
2...if a method is throwing a checked exception then either you need to catch it then and there only or you must specify a throws clause for the same in function definition......*And the purpose of not catching it then and there only is*
"For example, if you were providing the ListOfNumbers class as part of a package of classes, you probably couldn't anticipate the needs of all the users of your package. In this case, it's better to not catch the exception and to allow a method further up the call stack to handle it."
M I RIGHT??

Exception handling within a value-binding expression

Hi all,
Forgive me if this question seems odd, but I am a long-time Struts developer, new to JSF.
In Struts, exception handling was easy because all requests were funnelled through some subclass of Action. Exception handling could effectively be consolidated into one spot by applying the template-method pattern.
Of course, with JSF, this is not possible because method names in value-binding and action-binding expressions can be chosen arbitrarily. For this reason, I am exploring aspect-oriented (and other) techniques for consolidation JSF exception handling into one spot, but rather than focus too intently on that, it's clear that I first need the ability to forward to an error page when an exception is encountered in a value-binding or action-binding expression.
For action-binding expressions, ExternalContext.dispatch("<view id>"); seems to work quite well, but I am unable to make the same work when in the context of a value-binding expression. This is probably attributed to the fact that at that point, I am in an entirely different phase of the JSF request processing lifecycle.
What I'm looking to know is if anyone has a reliable means of forwarding to an error page within the context of a value-binding expression. Better yet, does anyone know a reliable way of forwarding to another view regardless of what phase you are in?
If it makes a difference (and I think it does) the error page uses JSF as well, and uses the same layout (provided via custom tags courtesy of JSP 2.0 tag files), so some view components would have the same name as the page which encountered the error. This seems to get in the way of me simply defining the error page for a 500 in my web deployment descriptor.
Thanks in advance to anyone with a working suggestion.
-Kent

Let me pose a purely hypothetical use case to demonstrate the problem:
Imagine a page in an HR app, employeeDetails.jsp, that displays an always-up-to-date combo box which lists employee names and IDs. onChange triggers a form submit with the intention of simply posting back to this page, with various text boxes, etc. below updated to show all information for the selected employee.
Obviously, with the requirement that the combo box always be up to date, it's clear that the getter invoked by the value-binding expression must access the database (not directly of course, but via a facade, application, then data-access layer). Any unexpected and unchecked exception in this chain would propagate back up to the getter method on the backing bean. I need to, at that point, log the exception (trivial) and forward to a user-friendly error page.
I suppose I could put some contraint on myself that data access is only performed within ActionEvent handlers, but I'm not sure that's consistent with the JSF model in general, in fact it almost seems Struts-like in that I'd have to invoke some action before loading this form to build the up-to-date list for the combo box, shove it in request scope, where it's then available to the page indicated by the navigation rules. Submission of the form on the page in question would also need to result in rebuilding the up-to-date list. Now we're looking at firther propagation of code. I want to avoid this, so I am looking for a better way.

Exception handling in run()

Hi,
now here is the situation
one of my classes that i made ClassA calls a run method of ClassB
ClassB in its run method calls a local method throwMethod() that throws an exception
now i want this exception to goto ClassA but because run method doesnot say
"Throws Exception" it is giving me some problem.
here is a sample code of what i am trying to accomplish:
public ClassA{
public static void main(){
ClassB b = new ClassB();
try{
b.run();}
catch (Exception ex){
System.out.println("yay Exception caught from classB's methodThrow "); //
}//main of classA
}//classA
publc ClassB implements Runnable{
run() throws exception //this is not valid as the run() in Runnable doesnot
//throw any exceptions.
methodThrow();
}//run of classB
public void methodThrow() thorws Exception{
throws new Exception("Goto classA");
}//methodThrow
}//ClassBthis is what i am trying to do and its not letting me do this..
i just want to ask this if a run method cannot throw any exception how i am supposed to handle exception if i want to handle that exception in the class calling the run of this class... or is it that i can only handle exception inside the run itself (which i cannot as this is not what i want to do..)
OR how can i tell the ClassA (which calls the ClassB.run() ) that the run method didnt execute properly so that ClassA can handle that situation properly like : put a system.out.println("the class didnt run"); or something
i would really appreciate the help...

They are not part of a method signature, but they are
part of the interface's contract, normally shown
using @throws tags in the documentation. The JLS
doesn't cover contracts, only the language. There's
plenty of examples in the standard API where the
interface's contract documents that a specific
runtime exception is thrown under certain
circumstances. But the fact that an unchecked exception is not described in the documentation doesn't mean that an implementing method must not throw it. So throwing any unchecked exception can never break a contract IMO, unless the docs specifically state that the exception must not be thrown, or must only be thrown in certain circumstances.
For example, calling Iterator.next()
after Iterator.hasNext() returns false breaks the
contract of the Iterator interface, and causes a
runtime exception to be thrown, but has no impact on
the method signatures when overriding them. Right. Following up with that, let's say I have an Iterator that is iterating over some sort of stream (reading bytes or lines or something). If the stream is interrupted, it's appropriate to throw an exception even though such behavior is not documented in the Iterator interface, and you would not break a contract to throw an exception.
The contract of
Runnable is that it may be called and not create any
recoverable exceptions, or else it will kill the
calling thread. If there was a good reason for
requiring the client to handle the exception, that
reason won't magically go away if you change it so
the compiler won't complain about it.Right. I had to think about it, but I don't see any advantage to crashing the thread versus logging the exception and gracefully finishing execution. So one might as well handle the exception rather than rethrowing it, since there will be no one (other than the VM) there to catch it.

Good exception handling policy for Java web application

I'm looking for a good exception handling policy for Java web application. First I found this Java exception handling best practices - How To Do In Java which says that you should never catch the Trowable class nor use e.printStackTrace();
Then I found this Oracle page The Message-Driven Bean Class - The Java EE 6 Tutorial, which does just that. So now I'm confused. Is there a good page online for an exception handling policy for Java EE Web applications? I have a hard time finding one. I've read that you should not catch the Exception class. I've been catching it previously to make sure that some unknown exception doesn't slip through early in the loop and stops all other customers from executing later on in the loop. We have a loop which runs once a minute implemented using the Quartz framework. Is it OK if you just change the implementation to catch the RuntimeException class instead of the Exception class? We're using Java 7 and the Jetty Servlet Container.

I'm looking for a good exception handling policy for Java web application.
If you have not done so I suggest you start by reviewing the several trails in The Java Tutorials.
Those trails cover both HOW to use exceptions and WHEN to use them.
This trail discusses the 'controversy' you mention regarding 'Unchecked Exceptions'
http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
Unchecked Exceptions — The Controversy
Because the Java programming language does not require methods to catch or to specify unchecked exceptions (RuntimeException, Error, and their subclasses), programmers may be tempted to write code that throws only unchecked exceptions or to make all their exception subclasses inherit from RuntimeException. Both of these shortcuts allow programmers to write code without bothering with compiler errors and without bothering to specify or to catch any exceptions. Although this may seem convenient to the programmer, it sidesteps the intent of the catch or specify requirement and can cause problems for others using your classes.
Why did the designers decide to force a method to specify all uncaught checked exceptions that can be thrown within its scope? Any Exception that can be thrown by a method is part of the method's public programming interface. Those who call a method must know about the exceptions that a method can throw so that they can decide what to do about them. These exceptions are as much a part of that method's programming interface as its parameters and return value.
The next question might be: "If it's so good to document a method's API, including the exceptions it can throw, why not specify runtime exceptions too?" Runtime exceptions represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way. Such problems include arithmetic exceptions, such as dividing by zero; pointer exceptions, such as trying to access an object through a null reference; and indexing exceptions, such as attempting to access an array element through an index that is too large or too small.
Generally don't catch an exception unless you plan to HANDLE the exception. Logging, by itself is NOT handliing.
First I found this Java exception handling best practices - How To Do In Java which says that you should never catch the Trowable class nor use e.printStackTrace();
That article, like many, has some good advice and some poor or even bad advice. You get what you pay for!
I've read that you should not catch the Exception class.
Ok - but all that does is indicate that a problem of some sort happened somewhere. Not very useful info. Java goes to a lot of trouble to provide specific exceptions for specific problems.
I've been catching it previously to make sure that some unknown exception doesn't slip through early in the loop and stops all other customers from executing later on in the loop.
If the exception is 'unknown' then maybe it NEEDS to 'stop all other customers from executing later on in the loop'.
That is EXACTLY why you don't want to do that. You need to identify which exceptions should NOT stop processing and which ones should.
Some 'unknown' exceptions can NOT be recovered and indicate a serious problem, perhaps with the JVM itself. You can NOT just blindly keep executing and ignore them without risking data corruption and/or the integrity of the entire system Java is running on.
Is it OK if you just change the implementation to catch the RuntimeException class instead of the Exception class? We're using Java 7 and the Jetty Servlet Container.
No - not if you want a well-behaved system.
Don't catch exceptions unless you HANDLE/resolve them. There are times when it makes sense to log the exception (which does NOT handle it) and then raise it again so that it gets handled properly later. Yes - I know that is contrary to the advice given in that article but, IMHO, that article is wrong about that point.
If you have ever had to maintain/fix/support someone else's Java code you should already understand how difficult it can be to find WHERE a problem occurs and WHAT the exact problem is when exceptions are not handled properly.

Checked or Unchecked Exceptions

I've had people explain the differences of checked exceptions and unchecked exceptions but I just can't seem to get it into my head. Can anyone help explain what the differences are?

Exceptions: Most programs throw and catch objects that derive from the Exception class. Exceptions indicate
that a problem occurred but that the problem is not a serious JVM problem. An Exception class has many
subclasses. These descendants indicate various types of exceptions that can occur. For example,
NegativeArraySizeException indicates that a program attempted to create an array with a negative size. One
exception subclass has special meaning in the Java language: RuntimeException. All the exceptions except
RuntimeException are compiler checked exceptions. If a method is capable of throwing a checked exception it
must declare it in its method header or handle it in a try/catch block. Failure to do so raises a compiler error. So
checked exceptions can, at compile time, greatly reduce the occurrence of unhandled exceptions surfacing at
runtime in a given application at the expense of requiring large throws declarations and encouraging use of poorlyconstructed
try/catch blocks. Checked exceptions are present in other languages like C++, C#, and Python.
Runtime Exceptions (unchecked exception)
A RuntimeException class represents exceptions that occur within the Java virtual machine (during runtime). An
example of a runtime exception is NullPointerException. The cost of checking for the runtime exception often
outweighs the benefit of catching it. Attempting to catch or specify all of them all the time would make your code
unreadable and unmaintainable. The compiler allows runtime exceptions to go uncaught and unspecified. If you
like, you can catch these exceptions just like other exceptions. However, you do not have to declare it in your
�throws" clause or catch it in your catch clause. In addition, you can create your own RuntimeException
subclasses and this approach is probably preferred at times because checked exceptions can complicate method
signatures and can be difficult to follow.

Exception handling - more

Okay, new day new questions.
What's better?
method ...() {
try {
doMethod1();
catch (exception) {
// handle error
try {
doMethod2();
catch (exception) {
// handle error
}or
method()...{
try {
doMethod1();
doMethod2();
catch (exception) {
// handle exception
}The question is readability and program flow. If you wrap up a chunk of a code block which contains methods that throw exceptions as well as those that don't, when you're reading back through it it's hard to know which methods throw exceptions and which don't. It's hard to see the flow of the program just by looking at the code.
But if you wrap up every method in a try/catch that can throw an exception you make it just as hard to see the program flow since you're dealing with multiple exceptions where each catch handles the error in much the same way. Instead of breaking out of the method at one place you could now be breaking out at several.
Comments? Suggestions?

There's one more: don't catch anything and declare your method to throw them, that way the calling method gets thrown an exception containing not only a full stack trace but also a (supposedly) descriptive message.
Of course we know that that is not always the case.
I think the "best" way depends on circumstances. I was asked at a job interview, "How do you decide whether to catch and exceptions in a method or to have them throw 'em on up?". My answer was to stammer around a bit, then reply very cleverly with "It depends."
HaHa, but I think it's true. It depends on the kind of program, the purpose of the method, and the potential uses of the method. (ps. the interviewer is now my boss, so maybe I was right?)
A story from my past life: there was once a class/method, originally never intended to be used outside of its package and the single use they had in mind when they designed it. Unfortunately, time proved that this package has some useful stuff and it grew into kindof an widely used API within the company. However the class/method to which I refer was responsible for open a Socket connection (from an IP address string and string port number) to a device and communicating some bytes back and forth to initialize the device (can you count how many checked much less unchecked things can come out of that before you even do any validity checking???). However, this constructor caught all of its exceptions and handled them by writing to some logging system that existed only in the original system). Therefore, years later when I was writing a GUI that used this class, my GUI had no way of knowing if anything was wrong, much less what actually was wrong.
The moral of the story is that I have come to believe in letting exceptions float up as high as reasonable, because you never know. (Of course I don't always practice this flawlessly.)
/Mel

MC.9 and MCY1 and Exception Handling in (Logistics Inf. Sys)LIS

Hi,
I want the 'Valuated Stock Value" greater then or equal to zero (>=) appear in the MC.9 report. I can create 'Exception' in MCY1 but am unable to do so. Once I am in MCY1; I choose 'Requirements' then Key Figure 'Valuated Stock Value' then 'Type of condition' is 'Threshold Val. Anal.' is set to '> 0'. However, the report still displays zero values in MC.9. I don't want to display 'Valuated Stock Value' zero to be displayed on the report. Please help.
Thanks
Naved

Hey Chris,
I got the point for exception handling in weblogic 9.2. We ae using 9.2. It comes up with the concept of shared page flows which means all my unhandled exceptions are thrown to the shared page flow controller. There based on the type of exception, i can forward the request to appropraite page.
Thanks anywyas,
Saurabh

PL/SQL 101 : Exception Handling

Frequently I see questions and issues around the use of Exception/Error Handling in PL/SQL. More often than not the issue comes from the questioners misunderstanding about how PL/SQL is constructed and executed, so I thought I'd write a small article covering the key concepts to give a clear picture of how it all hangs together. (Note: the examples are just showing examples of the exception handling structure, and should not be taken as truly valid code for ways of handling things)
Exception Handling
Contents
1. Understanding Execution Blocks (part 1)
2. Execution of the Execution Block
3. Exceptions
4. Understanding Execution Blocks (part 2)
5. How to continue exection of statements after an exception
6. User defined exceptions
7. Line number of exception
8. Exceptions within code within the exception block
1. Understanding Execution Blocks (part 1)
The first thing that one needs to understand is almost taking us back to the basics of PL/SQL... how a PL/SQL execution block is constructed.
Essentially an execution block is made of 3 sections...
+---------------------------+
|    Declaration Section    |
+---------------------------+
|    Statements Section    |
+---------------------------+
|     Exception Section     |
+---------------------------+
The Declaration section is the part defined between the PROCEDURE/FUNCTION header or the DECLARE keyword (for anonymous blocks) and the BEGIN keyword. (Optional section)
The Statements section is where your code goes and lies between the BEGIN keyword and the EXCEPTION keyword (or END keyword if there is no EXCEPTION section). (Mandatory section)
The Exception section is where any exception handling goes and lies between the EXCEPTION keyword at the END keyword. (Optional section)
Example of an anonymous block...
DECLARE
.. declarative statements go here ..
BEGIN
.. code statements go here ..
EXCEPTION
.. exception handlers go here ..
END;
Example of a procedure/function block...
[CREATE OR REPLACE] (PROCEDURE|FUNCTION) <proc or fn name> [(<parameters>)] [RETURN <datatype>] (IS|AS)
.. declarative statements go here ..
BEGIN
.. code statements go here ..
EXCEPTION
.. exception handlers go here ..
END;
(Note: The same can also be done for packages, but let's keep it simple)
2. Execution of the Execution Block
This may seem a simple concept, but it's surprising how many people have issues showing they haven't grasped it. When an Execution block is entered, the declaration section is processed, creating a scope of variables, types , cursors, etc. to be visible to the execution block and then execution enters into the Statements section. Each statment in the statements section is executed in turn and when the execution completes the last statment the execution block is exited back to whatever called it.
3. Exceptions
Exceptions generally happen during the execution of statements in the Statements section. When an exception happens the execution of statements jumps immediately into the exception section. In this section we can specify what exceptions we wish to 'capture' or 'trap' and do one of the two following things...
(Note: The exception section still has access to all the declared items in the declaration section)
3.i) Handle the exception
We do this when we recognise what the exception is (most likely it's something we expect to happen) and we have a means of dealing with it so that our application can continue on.
Example...
(without the exception handler the exception is passed back to the calling code, in this case SQL*Plus)
SQL> ed
Wrote file afiedt.buf
1 declare
2    v_name VARCHAR2(20);
3 begin
4    select ename
5    into   v_name
6    from   emp
7    where empno = &empno;
8    dbms_output.put_line(v_name);
9* end;
SQL> /
Enter value for empno: 123
old   7:   where empno = &empno;
new   7:   where empno = 123;
declare
ERROR at line 1:
ORA-01403: no data found
ORA-06512: at line 4
(with an exception handler, we capture the exception, handle it how we want to, and the calling code is happy that there is no error for it to report)
SQL> ed
Wrote file afiedt.buf
1 declare
2    v_name VARCHAR2(20);
3 begin
4    select ename
5    into   v_name
6    from   emp
7    where empno = &empno;
8    dbms_output.put_line(v_name);
9 exception
10    when no_data_found then
11      dbms_output.put_line('There is no employee with this employee number.');
12* end;
SQL> /
Enter value for empno: 123
old   7:   where empno = &empno;
new   7:   where empno = 123;
There is no employee with this employee number.
PL/SQL procedure successfully completed.
3.ii) Raise the exception
We do this when:-
a) we recognise the exception, handle it but still want to let the calling code know that it happened
b) we recognise the exception, wish to log it happened and then let the calling code deal with it
c) we don't recognise the exception and we want the calling code to deal with it
Example of b)
SQL> ed
Wrote file afiedt.buf
1 declare
2    v_name VARCHAR2(20);
3    v_empno NUMBER := &empno;
4 begin
5    select ename
6    into   v_name
7    from   emp
8    where empno = v_empno;
9    dbms_output.put_line(v_name);
10 EXCEPTION
11    WHEN no_data_found THEN
12      INSERT INTO sql_errors (txt)
13      VALUES ('Search for '||v_empno||' failed.');
14      COMMIT;
15      RAISE;
16* end;
SQL> /
Enter value for empno: 123
old   3:   v_empno NUMBER := &empno;
new   3:   v_empno NUMBER := 123;
declare
ERROR at line 1:
ORA-01403: no data found
ORA-06512: at line 15
SQL> select * from sql_errors;
TXT
Search for 123 failed.
SQL>
Example of c)
SQL> ed
Wrote file afiedt.buf
1 declare
2    v_name VARCHAR2(20);
3    v_empno NUMBER := &empno;
4 begin
5    select ename
6    into   v_name
7    from   emp
8    where empno = v_empno;
9    dbms_output.put_line(v_name);
10 EXCEPTION
11    WHEN no_data_found THEN
12      INSERT INTO sql_errors (txt)
13      VALUES ('Search for '||v_empno||' failed.');
14      COMMIT;
15      RAISE;
16    WHEN others THEN
17      RAISE;
18* end;
SQL> /
Enter value for empno: 'ABC'
old   3:   v_empno NUMBER := &empno;
new   3:   v_empno NUMBER := 'ABC';
declare
ERROR at line 1:
ORA-06502: PL/SQL: numeric or value error: character to number conversion error
ORA-06512: at line 3
SQL> select * from sql_errors;
TXT
Search for 123 failed.
SQL>
As you can see from the sql_errors log table, no log was written so the WHEN others exception was the exception that raised the error to the calling code (SQL*Plus)
4. Understanding Execution Blocks (part 2)
Ok, so now we understand the very basics of an execution block and what happens when an exception happens. Let's take it a step further...
Execution blocks are not just a single simple block in most cases. Often, during our statements section we have a need to call some reusable code and we do that by calling a procedure or function. Effectively this nests the procedure or function's code as another execution block within the current statement section so, in terms of execution, we end up with something like...
+---------------------------------+
|    Declaration Section          |
+---------------------------------+
|    Statements Section          |
|            .                    |
| +---------------------------+ |
| |    Declaration Section    | |
| +---------------------------+ |
| |    Statements Section    | |
| +---------------------------+ |
| |     Exception Section     | |
| +---------------------------+ |
|            .                    |
+---------------------------------+
|     Exception Section           |
+---------------------------------+
Example... (Note: log_trace just writes some text to a table for tracing)
SQL> create or replace procedure a as
2    v_dummy NUMBER := log_trace('Procedure A''s Declaration Section');
3 begin
4    v_dummy := log_trace('Procedure A''s Statement Section');
5    v_dummy := 1/0; -- cause an exception
6 exception
7    when others then
8      v_dummy := log_trace('Procedure A''s Exception Section');
9      raise;
10 end;
11 /
Procedure created.
SQL> create or replace procedure b as
2    v_dummy NUMBER := log_trace('Procedure B''s Declaration Section');
3 begin
4    v_dummy := log_trace('Procedure B''s Statement Section');
5    a; -- HERE the execution passes to the declare/statement/exception sections of A
6 exception
7    when others then
8      v_dummy := log_trace('Procedure B''s Exception Section');
9      raise;
10 end;
11 /
Procedure created.
SQL> exec b;
BEGIN b; END;
ERROR at line 1:
ORA-01476: divisor is equal to zero
ORA-06512: at "SCOTT.B", line 9
ORA-06512: at line 1
SQL> select * from code_trace;
TXT
Procedure B's Declaration Section
Procedure B's Statement Section
Procedure A's Declaration Section
Procedure A's Statement Section
Procedure A's Exception Section
Procedure B's Exception Section
6 rows selected.
SQL>
Likewise, execution blocks can be nested deeper and deeper.
5. How to continue exection of statements after an exception
One of the common questions asked is how to return execution to the statement after the one that created the exception and continue on.
Well, firstly, you can only do this for statements you expect to raise an exception, such as when you want to check if there is no data found in a query.
If you consider what's been shown above you could put any statement you expect to cause an exception inside it's own procedure or function with it's own exception section to handle the exception without raising it back to the calling code. However, the nature of procedures and functions is really to provide a means of re-using code, so if it's a statement you only use once it seems a little silly to go creating individual procedures for these.
Instead, you nest execution blocks directly, to give the same result as shown in the diagram at the start of part 4 of this article.
SQL> ed
Wrote file afiedt.buf
1 create or replace procedure b (p_empno IN VARCHAR2) as
2    v_dummy NUMBER := log_trace('Procedure B''s Declaration Section');
3 begin
4    v_dummy := log_trace('Procedure B''s Statement Section');
5    -- Here we start another execution block nested in the first one...
6    declare
7      v_dummy NUMBER := log_trace('Nested Block Declaration Section');
8    begin
9      v_dummy := log_trace('Nested Block Statement Section');
10      select empno
11        into   v_dummy
12        from   emp
13       where empno = p_empno; -- Note: the parameters and variables from
                                     parent execution block are available to use!
14    exception
15      when no_data_found then
16        -- This is an exception we can handle so we don't raise it
17        v_dummy := log_trace('No employee was found');
18        v_dummy := log_trace('Nested Block Exception Section - Exception Handled');
19      when others then
20        -- Other exceptions we can't handle so we raise them
21        v_dummy := log_trace('Nested Block Exception Section - Exception Raised');
22        raise;
23    end;
24    -- ...Here endeth the nested execution block
25    -- As the nested block handled it's exception we come back to here...
26    v_dummy := log_trace('Procedure B''s Statement Section Continued');
27 exception
28    when others then
29      -- We'll only get to here if an unhandled exception was raised
30      -- either in the nested block or in procedure b's statement section
31      v_dummy := log_trace('Procedure B''s Exception Section');
32      raise;
33* end;
SQL> /
Procedure created.
SQL> exec b(123);
PL/SQL procedure successfully completed.
SQL> select * from code_trace;
TXT
Procedure B's Declaration Section
Procedure B's Statement Section
Nested Block Declaration Section
Nested Block Statement Section
No employee was found
Nested Block Exception Section - Exception Handled
Procedure B's Statement Section Continued
7 rows selected.
SQL> truncate table code_trace;
Table truncated.
SQL> exec b('ABC');
BEGIN b('ABC'); END;
ERROR at line 1:
ORA-01722: invalid number
ORA-06512: at "SCOTT.B", line 32
ORA-06512: at line 1
SQL> select * from code_trace;
TXT
Procedure B's Declaration Section
Procedure B's Statement Section
Nested Block Declaration Section
Nested Block Statement Section
Nested Block Exception Section - Exception Raised
Procedure B's Exception Section
6 rows selected.
SQL>
You can see from this that, very simply, the code that we expected may have an exception was able to either handle the exception and return to the outer execution block to continue execution, or if an unexpected exception occurred then it was able to be raised up to the outer exception section.
6. User defined exceptions
There are three sorts of 'User Defined' exceptions. There are logical situations (e.g. business logic) where, for example, certain criteria are not met to complete a task, and there are existing Oracle errors that you wish to give a name to in order to capture them in the exception section. The third is raising your own exception messages with our own exception numbers. Let's look at the first one...
Let's say I have tables which detail stock availablility and reorder levels...
SQL> select * from reorder_level;
   ITEM_ID STOCK_LEVEL
         1          20
         2          20
         3          10
         4           2
         5           2
SQL> select * from stock;
   ITEM_ID ITEM_DESC STOCK_LEVEL
         1 Pencils             10
         2 Pens                 2
         3 Notepads            25
         4 Stapler              5
         5 Hole Punch           3
SQL>
Now, our Business has told the administrative clerk to check stock levels and re-order anything that is below the re-order level, but not to hold stock of more than 4 times the re-order level for any particular item. As an IT department we've been asked to put together an application that will automatically produce the re-order documents upon the clerks request and, because our company is so tight-ar*ed about money, they don't want to waste any paper with incorrect printouts so we have to ensure the clerk can't order things they shouldn't.
SQL> ed
Wrote file afiedt.buf
1 create or replace procedure re_order(p_item_id NUMBER, p_quantity NUMBER) is
2    cursor cur_stock_reorder is
3      select s.stock_level
4            ,r.stock_level as reorder_level
5            ,(r.stock_level*4) as reorder_limit
6      from stock s join reorder_level r on (s.item_id = r.item_id)
7      where s.item_id = p_item_id;
8    --
9    v_stock cur_stock_reorder%ROWTYPE;
10 begin
11    OPEN cur_stock_reorder;
12    FETCH cur_stock_reorder INTO v_stock;
13    IF cur_stock_reorder%NOTFOUND THEN
14      RAISE no_data_found;
15    END IF;
16    CLOSE cur_stock_reorder;
17    --
18    IF v_stock.stock_level >= v_stock.reorder_level THEN
19      -- Stock is not low enough to warrant an order
20      DBMS_OUTPUT.PUT_LINE('Stock has not reached re-order level yet!');
21    ELSE
22      IF v_stock.stock_level + p_quantity > v_stock.reorder_limit THEN
23        -- Required amount is over-ordering
24        DBMS_OUTPUT.PUT_LINE('Quantity specified is too much. Max for this item: '
                                 ||to_char(v_stock.reorder_limit-v_stock.stock_level));
25      ELSE
26        DBMS_OUTPUT.PUT_LINE('Order OK. Printing Order...');
27        -- Here goes our code to print the order
28      END IF;
29    END IF;
30    --
31 exception
32    WHEN no_data_found THEN
33      CLOSE cur_stock_reorder;
34      DBMS_OUTPUT.PUT_LINE('Invalid Item ID.');
35* end;
SQL> /
Procedure created.
SQL> exec re_order(10,100);
Invalid Item ID.
PL/SQL procedure successfully completed.
SQL> exec re_order(3,40);
Stock has not reached re-order level yet!
PL/SQL procedure successfully completed.
SQL> exec re_order(1,100);
Quantity specified is too much. Max for this item: 70
PL/SQL procedure successfully completed.
SQL> exec re_order(2,50);
Order OK. Printing Order...
PL/SQL procedure successfully completed.
SQL>
Ok, so that code works, but it's a bit messy with all those nested IF statements. Is there a cleaner way perhaps? Wouldn't it be nice if we could set up our own exceptions...
SQL> ed
Wrote file afiedt.buf
1 create or replace procedure re_order(p_item_id NUMBER, p_quantity NUMBER) is
2    cursor cur_stock_reorder is
3      select s.stock_level
4            ,r.stock_level as reorder_level
5            ,(r.stock_level*4) as reorder_limit
6      from stock s join reorder_level r on (s.item_id = r.item_id)
7      where s.item_id = p_item_id;
8    --
9    v_stock cur_stock_reorder%ROWTYPE;
10    --
11    -- Let's declare our own exceptions for business logic...
12    exc_not_warranted EXCEPTION;
13    exc_too_much      EXCEPTION;
14 begin
15    OPEN cur_stock_reorder;
16    FETCH cur_stock_reorder INTO v_stock;
17    IF cur_stock_reorder%NOTFOUND THEN
18      RAISE no_data_found;
19    END IF;
20    CLOSE cur_stock_reorder;
21    --
22    IF v_stock.stock_level >= v_stock.reorder_level THEN
23      -- Stock is not low enough to warrant an order
24      RAISE exc_not_warranted;
25    END IF;
26    --
27    IF v_stock.stock_level + p_quantity > v_stock.reorder_limit THEN
28      -- Required amount is over-ordering
29      RAISE exc_too_much;
30    END IF;
31    --
32    DBMS_OUTPUT.PUT_LINE('Order OK. Printing Order...');
33    -- Here goes our code to print the order
34    --
35 exception
36    WHEN no_data_found THEN
37      CLOSE cur_stock_reorder;
38      DBMS_OUTPUT.PUT_LINE('Invalid Item ID.');
39    WHEN exc_not_warranted THEN
40      DBMS_OUTPUT.PUT_LINE('Stock has not reached re-order level yet!');
41    WHEN exc_too_much THEN
42      DBMS_OUTPUT.PUT_LINE('Quantity specified is too much. Max for this item: '
                              ||to_char(v_stock.reorder_limit-v_stock.stock_level));
43* end;
SQL> /
Procedure created.
SQL> exec re_order(10,100);
Invalid Item ID.
PL/SQL procedure successfully completed.
SQL> exec re_order(3,40);
Stock has not reached re-order level yet!
PL/SQL procedure successfully completed.
SQL> exec re_order(1,100);
Quantity specified is too much. Max for this item: 70
PL/SQL procedure successfully completed.
SQL> exec re_order(2,50);
Order OK. Printing Order...
PL/SQL procedure successfully completed.
SQL>
That's better. And now we don't have to use all those nested IF statements and worry about it accidently getting to code that will print the order out as, once one of our user defined exceptions is raised, execution goes from the Statements section into the Exception section and all handling of errors is done in one place.
Now for the second sort of user defined exception...
A new requirement has come in from the Finance department who want to have details shown on the order that show a re-order 'indicator' based on the formula ((maximum allowed stock - current stock)/re-order quantity), so this needs calculating and passing to the report...
SQL> ed
Wrote file afiedt.buf
1 create or replace procedure re_order(p_item_id NUMBER, p_quantity NUMBER) is
2    cursor cur_stock_reorder is
3      select s.stock_level
4            ,r.stock_level as reorder_level
5            ,(r.stock_level*4) as reorder_limit
6            ,(((r.stock_level*4)-s.stock_level)/p_quantity) as finance_factor
7      from stock s join reorder_level r on (s.item_id = r.item_id)
8      where s.item_id = p_item_id;
9    --
10    v_stock cur_stock_reorder%ROWTYPE;
11    --
12    -- Let's declare our own exceptions for business logic...
13    exc_not_warranted EXCEPTION;
14    exc_too_much      EXCEPTION;
15 begin
16    OPEN cur_stock_reorder;
17    FETCH cur_stock_reorder INTO v_stock;
18    IF cur_stock_reorder%NOTFOUND THEN
19      RAISE no_data_found;
20    END IF;
21    CLOSE cur_stock_reorder;
22    --
23    IF v_stock.stock_level >= v_stock.reorder_level THEN
24      -- Stock is not low enough to warrant an order
25      RAISE exc_not_warranted;
26    END IF;
27    --
28    IF v_stock.stock_level + p_quantity > v_stock.reorder_limit THEN
29      -- Required amount is over-ordering
30      RAISE exc_too_much;
31    END IF;
32    --
33    DBMS_OUTPUT.PUT_LINE('Order OK. Printing Order...');
34    -- Here goes our code to print the order, passing the finance_factor
35    --
36 exception
37    WHEN no_data_found THEN
38      CLOSE cur_stock_reorder;
39      DBMS_OUTPUT.PUT_LINE('Invalid Item ID.');
40    WHEN exc_not_warranted THEN
41      DBMS_OUTPUT.PUT_LINE('Stock has not reached re-order level yet!');
42    WHEN exc_too_much THEN
43      DBMS_OUTPUT.PUT_LINE('Quantity specified is too much. Max for this item: '
                              ||to_char(v_stock.reorder_limit-v_stock.stock_level));
44* end;
SQL> /
Procedure created.
SQL> exec re_order(2,40);
Order OK. Printing Order...
PL/SQL procedure successfully completed.
SQL> exec re_order(2,0);
BEGIN re_order(2,0); END;
ERROR at line 1:
ORA-01476: divisor is equal to zero
ORA-06512: at "SCOTT.RE_ORDER", line 17
ORA-06512: at line 1
SQL>
Hmm, there's a problem if the person specifies a re-order quantity of zero. It raises an unhandled exception.
Well, we could put a condition/check into our code to make sure the parameter is not zero, but again we would be wrapping our code in an IF statement and not dealing with the exception in the exception handler.
We could do as we did before and just include a simple IF statement to check the value and raise our own user defined exception but, in this instance the error is standard Oracle error (ORA-01476) so we should be able to capture it inside the exception handler anyway... however...
EXCEPTION
WHEN ORA-01476 THEN
... is not valid. What we need is to give this Oracle error a name.
This is done by declaring a user defined exception as we did before and then associating that name with the error number using the PRAGMA EXCEPTION_INIT statement in the declaration section.
SQL> ed
Wrote file afiedt.buf
1 create or replace procedure re_order(p_item_id NUMBER, p_quantity NUMBER) is
2    cursor cur_stock_reorder is
3      select s.stock_level
4            ,r.stock_level as reorder_level
5            ,(r.stock_level*4) as reorder_limit
6            ,(((r.stock_level*4)-s.stock_level)/p_quantity) as finance_factor
7      from stock s join reorder_level r on (s.item_id = r.item_id)
8      where s.item_id = p_item_id;
9    --
10    v_stock cur_stock_reorder%ROWTYPE;
11    --
12    -- Let's declare our own exceptions for business logic...
13    exc_not_warranted EXCEPTION;
14    exc_too_much      EXCEPTION;
15    --
16    exc_zero_quantity EXCEPTION;
17    PRAGMA EXCEPTION_INIT(exc_zero_quantity, -1476);
18 begin
19    OPEN cur_stock_reorder;
20    FETCH cur_stock_reorder INTO v_stock;
21    IF cur_stock_reorder%NOTFOUND THEN
22      RAISE no_data_found;
23    END IF;
24    CLOSE cur_stock_reorder;
25    --
26    IF v_stock.stock_level >= v_stock.reorder_level THEN
27      -- Stock is not low enough to warrant an order
28      RAISE exc_not_warranted;
29    END IF;
30    --
31    IF v_stock.stock_level + p_quantity > v_stock.reorder_limit THEN
32      -- Required amount is over-ordering
33      RAISE exc_too_much;
34    END IF;
35    --
36    DBMS_OUTPUT.PUT_LINE('Order OK. Printing Order...');
37    -- Here goes our code to print the order, passing the finance_factor
38    --
39 exception
40    WHEN exc_zero_quantity THEN
41      DBMS_OUTPUT.PUT_LINE('Quantity of 0 (zero) is invalid.');
42    WHEN no_data_found THEN
43      CLOSE cur_stock_reorder;
44      DBMS_OUTPUT.PUT_LINE('Invalid Item ID.');
45    WHEN exc_not_warranted THEN
46      DBMS_OUTPUT.PUT_LINE('Stock has not reached re-order level yet!');
47    WHEN exc_too_much THEN
48      DBMS_OUTPUT.PUT_LINE('Quantity specified is too much. Max for this item: '
                              ||to_char(v_stock.reorder_limit-v_stock.stock_level));
49* end;
SQL> /
Procedure created.
SQL> exec re_order(2,0);
Quantity of 0 (zero) is invalid.
PL/SQL procedure successfully completed.
SQL>
Lastly, let's look at raising our own exceptions with our own exception numbers...
SQL> ed
Wrote file afiedt.buf
1 create or replace procedure re_order(p_item_id NUMBER, p_quantity NUMBER) is
2    cursor cur_stock_reorder is
3      select s.stock_level
4            ,r.stock_level as reorder_level
5            ,(r.stock_level*4) as reorder_limit
6            ,(((r.stock_level*4)-s.stock_level)/p_quantity) as finance_factor
7      from stock s join reorder_level r on (s.item_id = r.item_id)
8      where s.item_id = p_item_id;
9    --
10    v_stock cur_stock_reorder%ROWTYPE;
11    --
12    exc_zero_quantity EXCEPTION;
13    PRAGMA EXCEPTION_INIT(exc_zero_quantity, -1476);
14 begin
15    OPEN cur_stock_reorder;
16    FETCH cur_stock_reorder INTO v_stock;
17    IF cur_stock_reorder%NOTFOUND THEN
18      RAISE no_data_found;
19    END IF;
20    CLOSE cur_stock_reorder;
21    --
22    IF v_stock.stock_level >= v_stock.reorder_level THEN
23      -- Stock is not low enough to warrant an order
24      [b]RAISE_APPLICATION_ERROR(-20000, 'Stock has not reached re-order level yet!');[/b]
25    END IF;
26    --
27    IF v_stock.stock_level + p_quantity > v_stock.reorder_limit THEN
28      -- Required amount is over-ordering
29

its nice article, have put up this one the blog
site,Nah, I don't have time to blog, but if one of the other Ace's/Experts wants to copy it to a blog with reference back to here (and all due credit given ;)) then that's fine by me.
I'd go for a book like "Selected articles by OTN members" or something. Does anybody have a list of links of all those mentioned articles?Just these ones I've bookmarked...
Introduction to regular expressions ... by CD
When your query takes too long ... by Rob van Wijk
How to pipeline a function with a dynamic number of columns? by ascheffer
PL/SQL 101 : Exception Handling by BluShadow

Unchecked Exception Handling in an Applet

Similar Messages

Maybe you are looking for