Exception handling raised in named subprograms

Hi,
I would like to call three procedures from a when button pressed trigger and deal with them individually.
I tried naming the exception in the procedure, not to handle it there, and get it to propagate in the calling trigger.
Here is the code for the When-Button-Pressed Trigger:
declare
     too_much exception;
     begin
          p_valider_total_ht;
     :b_utils.f_nom := 'Everythingsfine' ;
     go_item( 'B_UTILS.F_NOM' );
exception
when others then
lib_alert(' Exc en pb valider ' || to_char(sqlcode) || 'xxx' || sqlerrm );
end;
Here is the code for the procedure:
PROCEDURE p_valider_total_ht
IS
     too_much exception;
BEGIN
     if :jbm_contrat.total_ht > 900 then
          raise too_much;
     end if;
     exception
          when too_much then
          raise;
when others then
lib_alert(' Exc en f_valider_total_ht ' || to_char(sqlcode) || 'yyy' || sqlerrm );
END;
It works, but the sqlcode contains: 1, wich means I can't distinguish between exceptions cases.
I tried the pragma exception init approach, but then Forms became really cross and threw a very big error message.
Many thanks for your help.

Hi,
It looks like pragma exception_init only works for existing Oracle error codes and messages.
I have written a function that returns 'OK' or KO' and the calling trigger raises an exception if 'KO' is returned.
Many thanks.

Similar Messages

Trying to raise a named exception, in an exception handler

We have some converted code that I'm trying to fix. Usually, the code isn't modularized, and is an EXCEPTION named at the top of a package gets raised, the code falls into the EXCEPTION handler and everything works fine.
create or replace package tmp_pg
as
procedure main;
end tmp_pg;
create or replace package body tmp_pg
as
x_datacheck EXCEPTION;
wk_num      NUMBER(1);
begin
wk_num := 1;
exception
when x_datacheck then
    raise_application_error(-20500, 'datacheck');
when others then
    raise;
end tmp_pg;
/The problem we're seeing for some of the code, is that inside the private methods in the PACKAGE BODY, the EXCEPTION defined at the PACKAGE BODY-level is raised, which results in a "ORA-06510: PL/SQL: unhandled user-defined exception" error:
create or replace package body tmp_pg
as
x_datacheck EXCEPTION;
wk_num      NUMBER(1);
procedure main is
begin
    if wk_num = 1 then
      raise x_datacheck;
    end if;
end main;
begin
wk_num := 1;
exception
when x_datacheck then
    raise_application_error(-20500, 'datacheck');
when others then
    raise;
end tmp_pg;So the code above compiles, but fails at runtime. I tried both of the following, which doesn't work:
- adding an exception handler in the procedure MAIN( ), which raises X_DATACHECK
procedure main is
begin
    if wk_num = 1 then
      raise x_datacheck;
    end if;
exception
    when x_datacheck then
      raise x_datacheck
end main;- adding a locally defined exception handler in MAIN( ), raising that, which in turn raises X_DATACHECK from the exception handler in MAIN( )
procedure main is
    lx_datacheck EXCEPTION;
begin
    if wk_num = 1 then
      raise lx_datacheck;
    end if;
exception
    when lx_datacheck then
      raise x_datacheck;
end main;Does anyone have another solution I could try?
Thanks,
--=Chuck

This block of code:
begin
wk_num := 1;
exception
when x_datacheck then
    raise_application_error(-20500, 'datacheck');
when others then
    raise;
end tmp_pg;executes only once, the first time the package is accessed in a session. Since it does not raise x_datacheck, the exception block will not catch it. When x_datacheck is raised in main, the initialisation section has already finished running, so main needs to be the one catching and re-raising. Something like:
SQL> create package tmp_pg as
2    procedure main;
3 end tmp_pg;
4 /
Package created.
SQL> create or replace package body tmp_pg as
2    x_datacheck EXCEPTION;
3    wk_num      NUMBER(1);
4
5    procedure main is
6    begin
7      if wk_num = 1 then
8        raise x_datacheck;
9      end if;
10    exception
11      when x_datacheck then
12        raise_application_error(-20500, 'datacheck');
13    end main;
14
15 begin
16    wk_num := 1;
17 end tmp_pg;
18 /
Package body created.
SQL> exec tmp_pg.main;
BEGIN tmp_pg.main; END;
ERROR at line 1:
ORA-20500: datacheck
ORA-06512: at "OPS$ORACLE.TMP_PG", line 12
ORA-06512: at line 1This would work even if some procedure called by main raised x_datacheck. If you want the initialisation section to catch x_datacheck, then either it needs to raise it itself, or call a procedure that raises x_datacheck.
John
John

Use of raise in exception handling block

what is the use of raise in exception handling block for eg.
declare
a number;
b emp.empno%type;
begin
begin
SELECT empno INTO a FROM emp where 1=2;
exception
when others then
dbms_output.put_line('inner');
raise;
end;
exception
when no_data_found then
dbms_output.put_line('outer');
end;
output will be like below ..
inner
outer
PL/SQL procedure successfully completed.
my question is wht is the use of using raise in exception handing part, is there any specific reason we use in the development ????
Regards,
AAK.

In the first block, you do not raise you user-defined exception WHEN_NO_DATA_FOUND, but the predefined one, which is raised to the WHEN OTHERS exception handler.
Consider:
SQL> declare
2     a number;
3     my_err exception;
4     no_data_found exception;
5 begin
6     begin
7        select 1 into a from dual where 1=2;
8     exception
9     when no_data_found then
10        dbms_output.put_line(' In system defined');
11        raise my_err;
12     end;
13 exception
14     when my_err then
15        dbms_output.put_line('In User Defined');
16     when others then
17        declare
18           v_sqlerrm varchar2(100);
19        begin
20           v_sqlerrm := sqlerrm;
21        dbms_output.put_line(' In when others '||sqlerrm);
22        end;
23 end;
24 /
In when others ORA-01403: no data found
PL/SQL procedure successfully completed.
SQL> ed
Wrote file afiedt.buf
1 declare
2     a number;
3     my_err exception;
4     --no_data_found exception;
5 begin
6     begin
7        select 1 into a from dual where 1=2;
8     exception
9     when no_data_found then
10        dbms_output.put_line(' In system defined');
11        raise my_err;
12     end;
13 exception
14     when my_err then
15        dbms_output.put_line('In User Defined');
16     when others then
17        declare
18           v_sqlerrm varchar2(100);
19        begin
20           v_sqlerrm := sqlerrm;
21        dbms_output.put_line(' In when others '||sqlerrm);
22        end;
23* end;
SQL> /
In system defined
In User Defined
PL/SQL procedure successfully completed.
SQL>Note that in the second block, I deleted the declaration of the user defined exception NO_DATA_FOUND.
This is taken from the documentation:
Redeclaring Predefined Exceptions
Remember, PL/SQL declares predefined exceptions globally in package STANDARD, so you need not declare them yourself. Redeclaring predefined exceptions is error prone because your local declaration overrides the global declaration. For example, if you declare an exception named invalid_number and then PL/SQL raises the predefined exception INVALID_NUMBER internally, a handler written for INVALID_NUMBER will not catch the internal exception. In such cases, you must use dot notation to specify the predefined exception, as follows:
EXCEPTION
WHEN invalid_number OR STANDARD.INVALID_NUMBER THEN
    -- handle the error
END;You can read yourself :
http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14261/errors.htm
Regards,
Gerd

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.

Exception handling in in insert statemnt

i am inserting values in to a table in a procedure.for insert statemnt what are the possible exceptions that may occur.
how to handle exceptions for that insert statement(other than when others)

user639995 wrote:
is there any possiblity to use if sql%rowcount = 0 then
RAISE e1;
like thisNot for an insert statement, no.
sql%rowcount returns the number of rows effected by a DML statement.
For any of the statements you can only check sql%rowcount after the DML statement successfully executes, and it will only return a 0 if no rows were effected by that DML statement e.g. if an update effected no rows or an insert ... select ... actually inserted no rows etc.
If an exception occurs during a DML statement then execution will pass directly to the exception handler so you won't have the opportunity to test for sql%rowcount after the statement.
You should have an exception handler for expected exceptions.
If an exception is not expected then you should let your code raise it up so it is seen and not handled.
example of defining exceptions for non-named error numbers...
SQL> create table x (x number);
Table created.
SQL> insert into x values ('x');
insert into x values ('x')
ERROR at line 1:
ORA-01722: invalid number
SQL> set serverout on
SQL> declare
2    ex_not_number exception;
3    pragma exception_init(ex_not_number, -1722);
4 begin
5    insert into x values (1);
6    commit;
7    insert into x values ('A');
8    commit;
9 exception
10    when ex_not_number then
11      dbms_output.put_line('An attempt to insert a value that is not a number was made.');
12 end;
13 /
An attempt to insert a value that is not a number was made.
PL/SQL procedure successfully completed.
SQL> select * from x;
         X
         1
SQL>Further details on exception handling here:
[PL/SQL 101 : Exception Handling|http://forums.oracle.com/forums/thread.jspa?threadID=697262&tstart=50]

FORALL Exception handling problem

Hi All,
I have one doubt in forall exception handling. I have gone through the SAVE EXCEPTION for bulk collect but i have one more query
BEGIN
FORALL j IN l_tab.first .. l_tab.last
INSERT INTO exception_test
VALUES (l_tab(i));
EXCEPTION
END;
My requirement is when an exception occurs, i ant to print the values of the collection.
e.g. say l_tab (j).emp_number, l_tab (j).emp_id.
How is that possible?
Thanks
Samarth
Edited by: 950810 on Mar 12, 2013 7:28 PM

>
I have one doubt in forall exception handling. I have gone through the SAVE EXCEPTION for bulk collect but i have one more query
BEGIN
FORALL j IN l_tab.first .. l_tab.last
INSERT INTO exception_test
VALUES (l_tab(i));
EXCEPTION
END;
My requirement is when an exception occurs, i ant to print the values of the collection.
e.g. say l_tab (j).emp_number, l_tab (j).emp_id.
How is that possible?
>
Post the code you are using. You didn't post the FORALL that is using SAVE EXCEPTIONS.
The SQL%BULK_EXCEPTIONS associative array that you get has the INDEX of the collection element that caused the exception.
So you need to use those indexes to index into the original collection to get whatever values are in it.
One index from the exception array is:
SQL%BULK_EXCEPTIONS(i).error_index So if your original collection is named 'myCollection' you would reference that collection value as:
myCollection(SQL%BULK_EXCEPTIONS(i).error_index); See 'Handling FORALL Exceptions (%BULK_EXCEPTIONS Attribute)' in the PL/SQL Language doc
http://docs.oracle.com/cd/B28359_01/appdev.111/b28370/tuning.htm#i49099
>
All exceptions raised during the execution are saved in the cursor attribute %BULK_EXCEPTIONS, which stores a collection of records. Each record has two fields:
%BULK_EXCEPTIONS(i).ERROR_INDEX holds the iteration of the FORALL statement during which the exception was raised.
%BULK_EXCEPTIONS(i).ERROR_CODE holds the corresponding Oracle Database error code.
The values stored by %BULK_EXCEPTIONS always refer to the most recently executed FORALL statement. The number of exceptions is saved in %BULK_EXCEPTIONS.COUNT. Its subscripts range from 1 to COUNT.
The individual error messages, or any substitution arguments, are not saved, but the error message text can looked up using ERROR_CODE with SQLERRM as shown in Example 12-9.
You might need to work backward to determine which collection element was used in the iteration that caused an exception. For example, if you use the INDICES OF clause to process a sparse collection, you must step through the elements one by one to find the one corresponding to %BULK_EXCEPTIONS(i).ERROR_INDEX. If you use the VALUES OF clause to process a subset of elements, you must find the element in the index collection whose subscript matches %BULK_EXCEPTIONS(i).ERROR_INDEX, and then use that element's value as the subscript to find the erroneous element in the original collection.

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

Delete Statement Exception Handling

Hi guys,
I have a problem in my procedure. There are 3 parameters that I am passing into the procedure. I am matching these parameters to those in the table to delete one record at a time.
For example if I would like to delete the record with the values ('900682',3,'29-JUL-2008') as parameters, it deletes the record from the table but then again when I execute it with the same parameters it should show me an error message but it again says 'Deleted the Transcript Request.....' Can you please help me with this?
PROCEDURE p_delete_szptpsr_1 (p_shttran_id IN saturn.shttran.shttran_id%TYPE,
p_shttran_seq_no IN saturn.shttran.shttran_seq_no%TYPE,
p_shttran_request_date IN saturn.shttran.shttran_request_date%TYPE) IS
BEGIN
DELETE FROM saturn.shttran
WHERE shttran.shttran_id = p_shttran_id
and shttran.shttran_seq_no = p_shttran_seq_no
and trunc(shttran_request_date) = trunc(p_shttran_request_date);
DBMS_OUTPUT.PUT_LINE('Deleted the Transcript Request Seq No (' || p_shttran_seq_no || ') of the Student (' || p_shttran_id ||') for the requested date of (' || p_shttran_request_date ||')');
COMMIT;
EXCEPTION WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE('Error: The supplied Notre Dame Student ID = (' || p_shttran_id ||
'), Transcript Request No = (' || p_shttran_seq_no || '), Request Date = (' || p_shttran_request_date || ') was not found.');
END p_delete_szptpsr_1;
Should I have a SELECT statement to use NO_DATA_FOUND ???

A DELETE statement that deletes no rows (just like an UPDATE statement that updates no rows) is not an error to Oracle. Oracle won't throw any exception.
If you want your code to throw an exception, you'll need to write that logic. You could throw a NO_DATA_FOUND exception yourself, i.e.
IF( SQL%ROWCOUNT = 0 )
THEN
RAISE no_data_found;
END IF;If you are just going to catch the exception, though, you could just embed whatever code you would use to handle the exception in your IF statement, i.e.
IF( SQL%ROWCOUNT = 0 )
THEN
<<do something about the exception>>
END IF;In your original code, your exception handler is just a DBMS_OUTPUT statement. That is incredibly dangerous in real production code. You are relying on the fact that the client has enabled output, that the client has allocated a large enough buffer, that the user is going to see the message, and that the procedure will never be called from any piece of code that would ever care if it succeeded or failed. There are vanishingly few situations where those are safe things to rely on.
Justin

Exception handling to catch the outcome of a select

Hello,
I want to use exception handling to exit me out of a function module. I want to have one exception for all errors.
For example, if this select statement does not work, how do I finish up this code to make it work.
error type cx_bsx
try
select * from t001 where BUKRS = '!@#$'
catch <not sure what> into INTO error
raise exception error
endtry.
When I use cx_bsx with the catch, nothing happens even though the select statement fails. Basically I want the catch to work in the same manner as this:
if sy-subrc ne 0.
raise error_table_read.
endif.

If this code is in a function module, then why not just use the function module exceptions.
if sy-subrc ne 0.
raise error_table_read.
endif.
What are you gaining by "catching" this exception in the function module. By using the "exceptions" part of the function module, you are passing this exception back to the calling program.
Regards,
Rich Heilman

Exception Handling Problem In BPM

All
I am facing an exception handling problem I am using BPM and , I have caught exception in the transformation step but when there is any data problem in that mapping(mentioned in the transformation)
it is not throwing the exception . is there any option to collect these type of system exception in the bpm and give a alert thru mail
is there any way to collect these type of exception happened in the BPE and raise alert thru generic alert
Thanks
Jayaraman

Hi Jayaraman,
When you say there is any data problem, does that fail the message mapping that you have defined?
If the message mapping used in the tranformation fails, it should raise an exception in the BPM.
Did you test the message mapping using the payload and see if it really fails or not?
Regards,
Ravi Kanth Talagana

Exception handling in rfcs and bapis

exception handling in rfcs and bapis

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

Exception handling for mis-addressed messages

We are using ebXML messaging in WLI. In many of our workflows we start new conversations with trading partners based on the contents of address fields in the messages. Now and again during development a message comes in which is addressed to a TP who doesn't exist. The message fails to be sent and rolls back repeatedly. Is there a simple way to remove these messages from the WLI hub? Can exception handling be used to move messages which are failing to enter the workflows to a special queue automatically?
thanks
Ben

Hi Holger,
I will not translate the coding into VB. So if you want to do this it is OK with me.
An idea would be after some testing by the community to provide the functionality as a DLL. This way it could also easily be added to a VB project.
However I assume that some developers prefer to integrate the coding themselves so that they might add additional customer specific functionlity.
For example not to raise an exception if a specific error is in the return parameter because they want to ignore it.
Best regards,
Andre

Exception Handling in bounded taskflows - expected behaviour

Hi,
I'm currently reviewing exception handling in bounded task flows and some things does not seems to be very clear for me.
(q1) Does it make sense that a bounded task flow calls a method (via a method activity) defined on the page definition of another page (outside of the BTF) by using a #{data.xxxmyPageDef.myMethodName.execute} EL expression?
(q2) Is is correct to expect the application to execute the method marked as ExceptionHandler in the taskflow, whenever an exception occurs?
(q3) I created 5 different scenarios where I call a service method which throws an exception, from within a page fragment of the BTF.
(q3 – sc1) Call a service method through the binding layer of the current page (by using #{bindings.xxx.execute})
Result: A dialog containing the exception message appears.
This is what I expected. Althought, the exception handler method does not seems to be invoked.(q3 – sc2) Call a service method through a task flow method activity using #{bindings.xxx.execute}
Result: A dialog containing the exception message appears.
This is what I expected. Althought, the exception handler method does not seems to be invoked.(q3 – sc3) Call a service method through a task flow method activity using #{data.myPageFragementPagedef.xxx.execute} (accessing the pageDef of the page fragment)
Result: Nothing happens.
This is not what I expected. Although, the exception handler method does nog seems to be invoked, I expect the ADF Error Handler to create a FacesMessage.(q3 – sc4) Call a service method through a task flow method activity using #{data.myPageContainingThePageFragmentPageDef.xxx.execute} (accessing the page containing the BTF region)
Result: Nothing happens.
This is not what I expected. Although, the exception handler method does nog seems to be invoked, I expect the ADF Error Handler to create a FacesMessage. (q3 – sc5) Call a service method through a task flow method activity using #{data.aPageOutsideTheBTFPageDef.xxx.execute} (accessing a page outside the BTW)
Result: Nothing happens.
This is not what I expected. Although, the exception handler method does nog seems to be invoked, I expect the ADF Error Handler to create a FacesMessage. (q4) How can it be possible that – without an exception handler – exceptions occur when calling method activities, without the exceptions being translated to FacesMessages?
Thanks in advance,
Koen Verhulst
JDeveloper 11.1.1.4

Koen,
+(q1) Does it make sense that a bounded task flow calls a method (via a method activity) defined on the page definition of another page (outside of the BTF) by using a #{data.xxxmyPageDef.myMethodName.execute} EL expression?+
No. Exceptions should be handled locally.
+(q2) Is is correct to expect the application to execute the method marked as ExceptionHandler in the taskflow, whenever an exception occurs?+
Only for exceptions that are before Render Response. The Render Response Phase is not handled in ADFc. So exceptions that occur in managed beans may fall through
+(q3) I created 5 different scenarios where I call a service method which throws an exception, from within a page fragment of the BTF.+
+(q3 – sc1) Call a service method through the binding layer of the current page (by using #{bindings.xxx.execute}) Result: A dialog containing the exception message appears.+
This is what I expected. Althought, the exception handler method does not seems to be invoked.
The binding layer has an error handler you can override in the DataBinings.cpx file
+(q3 – sc2) Call a service method through a task flow method activity using #{bindings.xxx.execute}+
Result: A dialog containing the exception message appears.
This is what I expected. Althought, the exception handler method does not seems to be invoked.
Again, you use the binding layer to invoke the service
+(q3 – sc3) Call a service method through a task flow method activity using #{data.myPageFragementPagedef.xxx.execute} (accessing the pageDef of the page fragment)+
Result: Nothing happens.
This is not what I expected. Although, the exception handler method does nog seems to be invoked, I expect the ADF Error Handler to create a FacesMessage.
Never use such a call. Its bad practice as there is no guarantee the container you reference is active. Always have the method call activity have its own binding defined when accessing a method call activity. I know there are lots of example floating aroundthat you #{data ...} and many are from 10.1.3. This should be avoided alltogether though
+(q3 – sc4) Call a service method through a task flow method activity using #{data.myPageContainingThePageFragmentPageDef.xxx.execute} (accessing the page containing the BTF region)+
Result: Nothing happens.
This is not what I expected. Although, the exception handler method does not seems to be invoked, I expect the ADF Error Handler to create a FacesMessage.
Again, this is not a proper use of the ADF framework.
+(q3 – sc5) Call a service method through a task flow method activity using #{data.aPageOutsideTheBTFPageDef.xxx.execute} (accessing a page outside the BTW)+
Result: Nothing happens. This is not what I expected. Although, the exception handler method does nog seems to be invoked, I expect the ADF Error Handler to create a FacesMessage.
accessing a page outside the BTW (!!!) This should ring a worst practices alarm on your laptop (obviously doesn't do it either)
+(q4) How can it be possible that – without an exception handler – exceptions occur when calling method activities, without the exceptions being translated to FacesMessages?+
Exceptions are not handled in a single place but stacked. The business service raises an exception and passes it to the binding layer if not handled. The binding layer handles the exception and if it can't passes it to ADFc. ADFc can handle this exception if it is not during Render Response.
Bottom line: There is no single point of exception handling. So as a recommendation for best practices
- Catch and handle exceptions as close as possible to their origins
- If things can go wrong, thy will - use try/catch blocks in managed beans
- Use an exception handling activity in all bounded task flows. In the case of task flow call activities being used exceptions can bubble up to the caller. However, this would take users out of their current application context
- Exceptions not handled in ADFc can be intercepted by overriding the application task flow exception handler (used by the exception handler activities). This would give you a chance e.g. to handle issues during Render Response
- Never fight the framework, never bend the framework: Don't use out of scope access to page definitions and resources. Exception handling is not a replacement for bad code practices (sorry for saying this, its not meant to be rude) :-)
Though I don't have a qualified numbers of bugs open for exception handling in ADF between 11.1.1.4 and now (and some that are open), but there are issues reported in this area. If there is something that really feels wrong, please go ahead and file a bug and provide a test case for development to have a look. The Render Response issue, for example is something we are aware of and that is in discussion (afaik knows, there is a change in exception handling in JSF 2 that may have an impact to what we can do in ADFc).
thanks
Frank

Exception Handling Within Methods

I'm currently looking over exception handling within Java and have what whats probably a very simple question to answer!
If within a method I have a try and catch block to handle all exceptions that the specific method may throw, do I then also need to specify the exceptions that the method will throw within its signature? (As I have already handled them).

After a bit more reading I think i've found my answer.
You only declare a method throws an exception if you wish to deal with it further up the method call stack. This raises another question though. If I did handle the exceptions that my method could throw within the method itself as well as declaring the method to throw the exceptions within its signature. What would happen?

Exception handling without BPM

Hello,
I have done exception handling with BPM.
i.e. when there exception comes in mapping I have use Block Exception Handler.
Can this be done without BPM.
Please snd me blog for it.
Regards

Hi,
As explained by Michal it is correct, but in message mapping , we can raise an alert .
See the below links
Alerts with variables from the messages payload (XI) - UPDATED - /people/michal.krawczyk2/blog/2005/03/13/alerts-with-variables-from-the-messages-payload-xi--updated
Triggering XI Alerts from a User Defined Function - /people/bhavesh.kantilal/blog/2006/07/25/triggering-xi-alerts-from-a-user-defined-function
Regards
Chilla

Exception handling raised in named subprograms

Similar Messages

Maybe you are looking for