stored proc > error doesn't fall in the exception block [message #188418] |
Fri, 18 August 2006 08:28 |
r2d2dev
Messages: 75 Registered: May 2005 Location: bxl
|
Member |
|
|
in my exception block of my stored proc i have some specific actions, but it seems that when this error occurs: "ORA-01850: hour must be between 0 and 23", it doesn't falles in the WHEN OTHERS block.
is this normal?
PROCEDURE test_cursor_2 (
p_recordset OUT cursor_type,
return_code_out OUT VARCHAR2,
return_message_out OUT VARCHAR2
)
IS
BEGIN
return_code_out := '00000';
return_message_out := 'OK';
OPEN p_recordset FOR
select col1, col2
from table1
where SYSDATE > TO_DATE (busi_servicedate, 'DD-MM-YYYY HH24:MI:SS');
EXCEPTION
WHEN OTHERS THEN
return_code_out := '43899';
return_message_out := 'Unknown error.';
END test_cursor_2;
it's not that the exceptions as a whole do not work in my stored proc, because i DO CAN catch the NO_DATA_FOUND exception when i add another exception for it.
WHY DOESN'T THE ERROR ABOVE FALL IN THE OTHERS BLOCK ????
[Updated on: Fri, 18 August 2006 08:32] Report message to a moderator
|
|
|
Re: stored proc > error doesn't fall in the exception block [message #188423 is a reply to message #188418] |
Fri, 18 August 2006 08:48 |
JRowbottom
Messages: 5933 Registered: June 2006 Location: Sunny North Yorkshire, ho...
|
Senior Member |
|
|
That would be because the error you are getting does not happen until you perform a FETCH from that cursor that attempts to return a row with invalid data.
Thus the exception isn't being raised in that code at all, but instead it comes from wherever you do a FETCH from that RefCursor
This is just one more example (if such a thing were needed) of why you should always STORE DATES IN COLUMNS OF TYPE DATE
<RANT>
What is this madness that overtakes developers and designers, and makes them think Quote: | Ooo. I need to store a date with a time component. Rather than putting it in a data type that will store just than, and validate it on entry as well, I'll put it in a free text string. That will be much safer, and there'll never be any problems with invalid data, or different NLS parameters causing different formats to appear, or not being able to use indexes on it
|
</RANT>
|
|
|
Re: stored proc > error doesn't fall in the exception block [message #188428 is a reply to message #188423] |
Fri, 18 August 2006 09:11 |
r2d2dev
Messages: 75 Registered: May 2005 Location: bxl
|
Member |
|
|
JRowbottom wrote on Fri, 18 August 2006 13:48 | STORE DATES IN COLUMNS OF TYPE DATE
|
I know, you are right on this, but designers thought years ago that it would reduce a lot of overhead when passing dateformats to other applications.
JRowbottom wrote on Fri, 18 August 2006 13:48 | it comes from wherever you do a FETCH from that RefCursor.
|
I don't completely understand this.
So you mean that the stored procedure correctly completes (without falling in exception), and all code after this "open p_recordset for..." is also completed with success ?
[Updated on: Fri, 18 August 2006 09:11] Report message to a moderator
|
|
|
Re: stored proc > error doesn't fall in the exception block [message #188430 is a reply to message #188428] |
Fri, 18 August 2006 09:22 |
JRowbottom
Messages: 5933 Registered: June 2006 Location: Sunny North Yorkshire, ho...
|
Senior Member |
|
|
Here's an example to show where the error happens:
CREATE TABLE test_data (col_1 VARCHAR2(10), date_col VARCHAR2(30));
INSERT INTO test_data VALUES ('A','01-jan-2006 23:59:59');
INSERT INTO test_data VALUES ('A','01-jan-2006 25:59:59');
CREATE OR REPLACE PROCEDURE test_cursor AS
TYPE c_ref IS REF CURSOR;
p_recordset c_ref;
p_1 VARCHAR2(30);
p_2 VARCHAR2(30);
BEGIN
OPEN p_recordset FOR
SELECT col_1, date_col
FROM test_data
WHERE SYSDATE > TO_DATE (date_col, 'DD-mon-YYYY HH24:MI:SS');
DBMS_OUTPUT.PUT_LINE('Cursor Opened');
FETCH p_recordset INTO p_1,p_2;
DBMS_OUTPUT.PUT_LINE('First Fetch');
FETCH p_recordset INTO p_1,p_2;
DBMS_OUTPUT.PUT_LINE('Second Fetch');
CLOSE p_recordset;
EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR(-20001,'Error '||SQLERRM);
END test_cursor;
/
SQL> SET SERVEROUTPUT ON SIZE 10000
SQL> BEGIN
2 test_cursor;
3 END;
4 /
Cursor Opened
First Fetch
BEGIN
*
ERROR at line 1:
ORA-20001: Error ORA-01850: hour must be between 0 and 23
ORA-06512: at "FPS.TEST_CURSOR", line 25
ORA-06512: at line 2
As you can see, the cursor is opened correctly (the first Dbms_output message is shown), and the first fetch happens (2nd message).
The exception is raised at the second FETCH statement.
So, in answer to your question, yes, the stored procedure that you posted will complete and the code after it will run until it tries to fetch an invalid row.
|
|
|
Re: stored proc > error doesn't fall in the exception block [message #188435 is a reply to message #188418] |
Fri, 18 August 2006 09:54 |
r2d2dev
Messages: 75 Registered: May 2005 Location: bxl
|
Member |
|
|
@JRowbottom:
so in my example above, it is my java program that is fetching in the cursor.
the cursor is executed towards the database (after the stored proc ends) as a corrupt select-statement ?
the only difference is that my java program falls in exception due to this corrupt statement, with the errorcode that oracle now returns with that corrupt select statement?
correct?
|
|
|
|