What King of exception handling is done in OA framework code?

Hi All,
I am not a core java person but have to do some OA framework code changes.Wanted to know what kind of exception handling is done in OAF codes?
I was looking as the seeded oracle controllers and dont see any try catch blocks.
can anyone guide me?

OAF java based framework, hence exception handling is similar to how its done in core java. I would advuce to better go through exception handling concepts of core java.
--Mukul

Similar Messages

Today updated my iphone 4 to ios 7.0.4 and now code is required, what never happend before and i don't know the code

hi need your help.
updted my iphone 4 today on ios 7.0.4 and now with new start code required, what i never had before and i don't know the code.
how can i get this problem solved?
thx
peter

Here's how you put it into recovery mode
1: Turn off your iPHone by holding the sleep/wake button till it says "Slide to power off."
2: Hold down the home button (Button on the bottom of the display with a square in the middle) and connect it to the computer while still holding it down till you see a music note with an arrow pointing towards it appear on the screen of your iPhone
3: iTunes will give you a message, "iTunes has detected a device in recovery mode; you must restore this device to factory settings to use this device."
4: Click on "Restore iPHone."
http://support.apple.com/kb/HT1808 if you want apple article steps

Exception handling-filter out a specific JBO code number

Hi
First i would like to explain that what i'm trying to achieve is 'filtering out' a specific error code using
JboException getErrorCode() these exceptions are thrown by
using JCLoginDialog and entering invalid user/password.
I am using bc4j/jclient application developed using JDeveloper 9.0.3. and JDK1.4.2
With that I'm also using the JAAS login feature,using the JCLoginDialog class.
Everything works except when I enter a invalid user/password in the jclientlogindialog.this class has a method called getInfo(info,connEnvironment) and within this method are 'if statements' that should set the error message in the case where a invalid user/password is entered, or if the 'Cancel' button is pressed it sets a error message to "Login Cancelled".
With my application this isn't working.
So Im trying to filter out JBO error codes but when these
errors occur, for example a invalid user/password is supplied,there are numerous errors and JBO code numbers in the detail stack output.
If i try to get a JBO code number using the JboException classes' getErrorCode() it returns the first JBO-Code number it finds,but not the one i need which would be the error caused by invalid user/password.
Thanx in advance, any help is really appreciated!
Carl

Carl:
Try looking into detail exceptions and their err code. The following example method does recursive look into all details:
 boolean foundMatch(String errCode, JboException ex)
 if (errCode.equals(ex.getErrorCode()))
 return true;
 Object[] dtls = ex.getDetails();
 for (int j = 0; dtls != null && j < dtls.length; j++)
 if (dtls[j] instanceof JboException)
 if (foundMatch(errCode, (JboException) dtls[j]) == true)
 return true;
 return false;
 }Thanks.
Sung

What is the best way of Exception Handling

There are many ways to handle the exceptions of a program.
1: You could put every exception handler in the most upper abstract classes.
2: You could write a generic exception that handles a lot of things.
3: You could write exceptions handling for every class.
4: you could group the exception handling.
many, many more ways.
Question:
What is the best way to do this?

There are many ways to handle the exceptions of a program.
1: You could put every exception handler in the most upper abstract classes.I woldn't do that always, a class may throw an exception if it's not able to handle it prperly, but it may, so it'll catch it. Throw Exception in abract supper clases only when you are sure the children must always throw the exception, not processing it.
2: You could write a generic exception that handles a lot of things.Bad idea, if you always throw an Exception no informtaion is provaided about whta happened, if you throw a NullPointerException and a NumberFormatException in one of your method I (for example) colud handle properly both problems, one likely to be a programming erros, so check my cod eagain, and the other like to be an user error in introduciong some data, so I wold ask him for the data again.
3: You could write exceptions handling for every class.Write exceptions handling for every class that needs it, throwing the exception if at that moment you don't know what to do with it and catching it if yes. Do not employ too many exception handling: execution of try catch blcks is slower than usuall code.
4: you could group the exception handling.I don't undestand this. What do youmean?
Question:
What is the best way to do this? In general thrwo an exception if the class dosen't know what to do with it, the class which uses yours will handle it. If your class can process the Exception, don't be too lazy and process it.
Employ exceptions always you need them but do not abuse; thay made the code execute slower because the VM machine must check if the exceotions occur.
abraham.

Exception handling in ucm

hi,
I have created a custom component that has a service which invokes my custom java methods. I would like to redirect to two error pages depending on the exception thrown by the java method? How exception handling is done in UCM. I see a text box called error messages while creating the service and service actions. But that message is not printed when my java method throws application specific exceptions.
Is there a way to handle the exception at Service configuraration / UI side and redirect to two different meaningful error pages dependinf upon the thye of exception
Thanks,
Siva

Hi Jayakrishna,
In General , there are non execptions in BAPIs, because of the reason, that the exception raised in a SAP envoronment may not mean anything for a non SAP initiator. All the exception situations would only fill the return table(TYpe BAPIRET2 or something like that). If you read that table after the call to the bapi, you can understand what has gone wrong.
Regards,
Ravi

Is Exception handler necessary for every stored subprogram

Hi All,
I knwo exception handler is very important. But is it necessary for every stored procedure or function?
For example,
procedure test(p_index_code IN varchar2(10)
p_changed_code OUT varchar2(15))
as
begin
IF p_index_code = 'A' then
p_changed_code := 'A'|| p_index_code;
elsif p_index_code = 'B' then
p_changed_code := 'B'|| p_index_code;
else
p_changed_code := p_index_code;
end if;
end;
This kind of simple procedures, do I have to add the 'exection when others than raise_application_error(-20001,'error in this SP')'?
I can't see obvious drawbacks without the exception handler in this CASE.
Best regards,
Leon
Edited by: user12064076 on Nov 11, 2010 7:12 PM

user12064076 wrote:
I knwo exception handler is very important. But is it necessary for every stored procedure or function?It is important to know WHY an exception handler is needed. There are couple of basic reasons why you want to use an exception handler.
The exception is not an error.
The exception raised is a technical error, but may not be a business or processing error. The typical example is the NO_DATA_FOUND exception. The business logic may say "+when there is no fixed discounts found, apply a 5% dis-count+". So not finding (dis-count) row data in such a case is not an exception. What does you exception handler do? It fixes the exception and there is not an exception anymore. In other words, the caller that called your code will never know that there was an exception.
Making the exception meaningful
An exception, like NO_DATA_FOUND, is not very meaningful. What is meaningful is NO_INVOICE_FOUND or NO_CUSTOMER_FOUND. Thus your exception handler can catch a generic exception and make it more meaningful by returning a custom application exception instead.
Action stations
Some exceptions will require you to clean up and fix what you can - kind of like action stations when a ship takes a hit. But as you cannot fix the exception, the exception must be passed to the caller so that it too can decide how to re-act to that exception. For example, you may have an open ref cursor or open UTL_FILE handle that needs to be closed when your code terminates. If not, your code will leak resources. So you need to trap exceptions that can occur, clean up, and then re-raise the exception (this is called a resource protection code block in other languages). You may have done a partial transaction - and the exception handler may need to roll back the changes your code made. The bottom line here is that you must re-raise the exception after you have done your "+action stations+" bit. You did not fix the exception. You did not make it more meaningful. In that case you must pass it back to the caller so that it can decide what it needs to do about that exception.
Using an exception for any other reason - that would likely be the wrong thing to do most of the time.

Defensive programming vs exception handling

Hi
im new to java programming and having problems getting my head around defensive programming vs exception handling.
i've read in my uni books about design by contract and the idea of defensive programming but im having problems with it.
so say i write the code.
String container = //some value
if (container.equals.("")) // so if i am looking for a value and find a empty String
   throw new // a custom exception i have made for this error.
else
   //do whatever i had planned with a non-empty String
}is this Defensive programming or exception handling. Or am i complete of base.
thanks

jverd wrote:
JustSomeGuy wrote:
Don't fall into the trap of saying "Meh, the exception will handle it". If you can forsee something easily being a problem, and it can be controlled, then control it. Save the exception handling for those things you don't forsee and those you can't control. I disagree. Or at least, I disagree with what I think you're saying.
For instance, if null is not a valid argument, then document it, and don't waste code defending against it. Either throw an explicit IllegalArgumentException, or let the NPE be thrown.
And absolutely under no circumstances should you ever write code that will deliberately lead to an exception, Eh? If an exceptional condition occurs, you should delibrately throw an exception. Consider if you will the following code snippet
import java.io.*;
class ExceptionExample {
    public static void main(String[] args)
        throws IOException {
        if (args.length == 0) {
            System.out.println("Must give filename as first arg.");
            return;
        FileInputStream in;
        try {
            in = new FileInputStream(args[0]);
        catch (FileNotFoundException e) {
            System.out.println("Can't find file: " + args[0]);
            return;
        int ch;
        while ((ch = in.read()) != -1) {
            System.out.print((char) ch);
        System.out.println();
        in.close();
} What I was saying in the first part is shown with the following part of the above code
if (args.length == 0) {
   System.out.println("Must give filename as first arg.");
   return;
} Would the exception handler that follows this peice of code have taken care of that? Sure! Would it be the best choice to just let the exception handler do it? No way no how!
It is easy to forsee someone forgetting or not realizing they need to add the filename as an arg and it can be controlled, so in this and most cases just like it the best choice is to either inform the user with a more specific statement than could be used in the exceptionhandler and do nothing or fix it yourself like for instance by using a default filename.
What I meant by deliberately throwing an exception can be illustrated with this small portion of my code above
int ch;
while ((ch = in.read()) != -1) {
    System.out.print((char) ch);
} A -1 to mark the EOF is expected and reaching the EOF is expected. There is absolutely nothing abnormal about this, so it should not be handled by an exception. But far to often I have seen novice and especially "think they know it all novices" use an exception in place of exactly this. They know the file will end, they know they must do something about that, but instead of doing it right they just set it up so an exception will be thrown and they can just handle it in the exceptionhandler. This is what I meant by deliberately throwing exceptions, in that an exception must be thrown in order for their program to work as intended. Bad, very bad.
Now that I have provided an example and further clarified my position do you still disagree? I can't imagine you would, so if you do I would be very interested in getting some further insight into your reasoning.
JSG

Public exception handler in database package

I'm working on Oracle 10 g; I have a package with 10 functions, instead of writing exception for each individually is there is a way to do the same exception handler in all without repeating the exception handler in the 10 function (my exception handler is the same for the 10 function)

It would depend on how you are using the functions, and what exactly your exception handler does.
If, for example, your handler for no_data_found does a specific select statement, then you could put this statement in another function and call that function in the exception handler of each of the 10 functions. Note that you would need to catch the exception in eacg function, but the common code would be in one place. Something like:
FUNCTION error_func RETURN NUMBER IS
BEGIN
   SELECT other_stuff INTO var;
   RETURN var;
END;
function1 RETURN NUMBER IS;
BEGIN
   SELECT stuff INTO var;
   RETURN var;
EXCEPTION
   WHEN NO_DATA_FOUND
      effor_func;
END;
function2 RETURN NUMBER IS;
BEGIN
   SELECT stuff INTO var;
   RETURN var;
EXCEPTION
   WHEN NO_DATA_FOUND
      effor_func;
END;
function3 RETURN NUMBER IS;
BEGIN
   SELECT stuff INTO var;
   RETURN var;
EXCEPTION
   WHEN NO_DATA_FOUND
      effor_func;
END;If you always run all 10 functions in sequence, then you could make a wrapper to call the functions, and catch exceptions in the wrapper. Something along the lines of:
FUNCTION wrapper RETURN NUMBER IS;
BEGIN
   function1;
   function2;
   function10;
EXCEPTION
   WHEN NO_DATA_FOUND THEN
      do something;
END;As constructed here, the wrapper wil not know which function errored nor will it continue running the other functions after getting an error.
John

Exceptions Handling Programs Needed! Pls!!!

Hi!
Can any one give some sample programs of how exception handling is done in abap.
Pls send it guys looking for your reply.
[email protected]
Rahul.

Hi,
Exceptions are situations that occur while an ABAP program is being executed, in which normal continuation of the program does not make any sense.
Exceptions can be raised either implicitly in the ABAP runtime environment or explicitly in the ABAP program.
For example, division by zero leads to an exception in the ABAP runtime environment. It is possible to determine this situation through a query in the ABAP program and to trigger an exception there.
See the demo program DEMO_HANDLE_EXCEPTIONS in se38.
*-------------------------------------EXAMPLE FOR RUNTIME ERROR---------------------------------------------------------------------------
*DATA : VALUE1 TYPE I.
*VALUE1 = 1 / 0. "------------->>>>>> IT MAKES RUN TIME ERROR.
*WRITE : VALUE1.
*---------------------------------EXAMPLE FOR HOW TO CATCH THE ARITHMETIC ERROR AT THE RUN TIME USING SUBRC---------------------------------
*DATA : VALUE1 TYPE I.
*CATCH SYSTEM-EXCEPTIONS ARITHMETIC_ERRORS = 1.
*VALUE1 = 1 / 0.
*WRITE : VALUE1.
*ENDCATCH.
*IF SY-SUBRC = 1.
*WRITE : ' IT MAKES ERROR'.
*ELSE.
*WRITE : VALUE1.
*ENDIF.
in abap program we handle exceptions based on value returned by the system variable SY-SUBRC.
if SY-SUBRC = 0.
means execution completed sucessfull.
if SY-SUBRC = 1........n.
means execution compleated not sucessfully.
if sy-sbrc = 0.
write:/ 'execution sucessfull.
**here write logic as per u r requirement
else sy-subrc = '1'
message
elseif sy-subrc eq '2'
message
elseif sy-subrc eq '3'
message
elseif sy-subrc eq '4'
message
endif
messages are defined in SE91..
these messages are 5 types..
A Termination Message
The message appears in a dialog box, and the program terminates. When the user has confirmed the message, control returns to the next-highest area menu.
E Error Message
Depending on the program context, an error dialog appears or the program terminates.
I (nformation)
The message appears in a dialog box. Once the user has confirmed the message, the program continues immediately after the MESSAGE statement.
S(Status Message)
The program continues normally after the MESSAGE statement, and the message is displayed in the status bar of the next screen.
W(Warning)
Depending on the program context, an error dialog appears or the program terminates.
X(Exit)
No message is displayed, and the program terminates with a short dump. Program terminations with a short dump normally only occur when a runtime error occurs. Message type X allows you to force a program termination. The short dump contains the message ID.
regards,
Ashokreddy.

Is Exception Handling in every Java code?

Hi there,
just curious, is including exception handling the "norm" for any Java code?

Java divide the exception handling in two kinds :
- exceptions which need to be programatically handled
- exceptions which are automatically handled by Java such as ArrayIndexOutOfBounds, DivisionByZero, and lot of subclasses of RuntimeException.
It's not because they are automatically handled that you can't handle them programatically, but programming will be too difficult and long if they wasn't handled automatically.
Exception mechanism is very powerfull but a little bit long when an exception is thrown.
Denis

What is the idea behind Render Response and Exception Handling in TF?

Dear All,
While searching for answer for my question, I find it hard to decipher this line.
task flow exception handling doesn't handle any exception that is in Render Response phase
I found this several times in many post like this.
Re: ADF Exception handling (including RENDER RESPNSE PHASE)
and this
Re: Exception Handling in TaskFlow
What's the idea behind exception handling in task flow that is related to JSF/ADF life cycle?
I can't find a resource on why I should know what phase an exception has been thrown?
Sorry if my question might be vague/ignorant to others, but I just would like to know the idea from experts around here. :)
Thanks.
JDEV 11G PS4

Hi,
Render Response is the last lifecycle phase processed during JSF request. The ADF controller has no chance of handling exceptions that occur during this time (example, exception thrown in managed bean) and therefore in its default exception handling implementation ignores this lifecycle phase. As an application developer you don't need to know when an exception is raised. However, if you find that an exception occurs during Render Response and it is not handled by the ADFc declarative exception handler, then you know. You can try and override the framework exception handler as explained here:
https://blogs.oracle.com/jdevotnharvest/entry/extending_the_adf_controller_exception_handler
However, better practice is to use try/catch blocks surrounding e.g. calls in a managed bean that could cause exceptions
Frank

What are the best practices for exception handling in n-tier applications?

What are the best practices for exception handling in n-tier applications?
The application is a fat client based on MVVM pattern with .NET framework.

What are the best practices for exception handling in n-tier applications?
The application is a fat client based on MVVM pattern with
.NET framework.
That would be to catch all exceptions at a single point in the n-tier solution, log it and create user friendly messages displayed to the user.

A catch-all "exception handler" - what's the end of an stack trace?

I've created an application that is beeing tested these days, and I thought it would be a good idea to implement a "catch-all" exception handler so that I could notify the user when an exception occur (so that he may stop, send me the log, and to prevent errors that occur as a result of the first one).
The way I've started implementing it is I redirect error out to a custom output stream:
public class ConsoleOutStream extends ByteArrayOutputStream {
 private JFrame owner;
 public ConsoleOutStream(JFrame owner) {
 this.owner = owner;
 * Writes <code>len</code> bytes from the specified byte array
 * starting at offset <code>off</code> to this byte array output stream.
 * @param b the data.
 * @param off the start offset in the data.
 * @param len the number of bytes to write.
 public synchronized void write(byte b[], int off, int len) {
 super.write(b, off, len);
 checkForExceptions();
 * Writes the specified byte to this byte array output stream.
 * @param b the byte to be written.
 public synchronized void write(int b) {
 super.write(b);
 checkForExceptions();
 private void checkForExceptions() {
 reset();
 if(this.toString().indexOf("xception") != -1) {
 System.out.println("Exception!!\n\n");
 System.out.println(this.toString());
}then i redirect System.err:
PrintStream out = new PrintStream(new ConsoleOutStream(this));
System.setErr(out);
The problem is that the checkForExceptions() method will be called, e.g. 3 times for each exception - and I just want to display an error message to the user once (of course).
Anyone done something similar?

I'm interested in catching all "unhandled errors"how about:
public static void main(String[] args){
 try{
 //whatever you would normally call from main
 }catch (Throwable e){
 System.out.println("There was an unhandled exception:");
 e.printStackTrace();
}

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

How to display the 500-internal server error on the Exception Handler page

Hello
My situation is as follows : JDev 11.1.1.0.2, ADF fusion application, one unbounded task flow containing 2 view pages view1.jspx and error.jspx
The error jspx is marked as the exception handler.
When an error occurs (typically a 500-Internal Server Error) the error.jspx is correctly displayed and shows our message such as 'Don't panic, please call our tech support'
What I would like to do is to display the actual error stack on this page along with our message.
I've searched around and I can't find how to either get the error stack in a bean or what EL expression should be used to get the error stack.
Can anybody help ?
Best Regards
Paul
Switzerland

The error will be the same, but the stack trace will be different, such as
Error 500--Internal Server Error
oracle.adf.controller.security.AuthorizationException: ADFC-0619: Echec de la vérification des autorisations : '/view1.jspx' 'VIEW'.
     at oracle.adf.controller.internal.security.AuthorizationEnforcer.handleFailure(AuthorizationEnforcer.java:145)
     at oracle.adf.controller.internal.security.AuthorizationEnforcer.checkPermission(AuthorizationEnforcer.java:124)
     at oracle.adfinternal.controller.state.ControllerState.initializeUrl(ControllerState.java:639)
     at oracle.adfinternal.controller.state.ControllerState.synchronizeStatePart2(ControllerState.java:449)
     at oracle.adfinternal.controller.application.SyncNavigationStateListener.afterPhase(SyncNavigationStateListener.java:44)
     at oracle.adfinternal.controller.lifecycle.ADFLifecycleImpl$PagePhaseListenerWrapper.afterPhase(ADFLifecycleImpl.java:529)
     at oracle.adfinternal.controller.lifecycle.LifecycleImpl.internalDispatchAfterEvent(LifecycleImpl.java:118)
     at oracle.adfinternal.controller.lifecycle.LifecycleImpl.dispatchAfterPagePhaseEvent(LifecycleImpl.java:166)
     at oracle.adfinternal.controller.faces.lifecycle.ADFPhaseListener$PhaseInvokerImpl.dispatchAfterPagePhaseEvent
What I would like is to display the above stack trace on the page marked as the exception handler....
Regards
Paul

What King of exception handling is done in OA framework code?

Similar Messages

Maybe you are looking for