The problem is you're raising no_data_found
, which is not treated as an exception by the cursor in bar
- it's valid for a select
(which the cursor you open
is, effectively) to return no rows. When you run your anonymous block you are only seeing the dbms_output
call, not a raised exception - the block completes successfully, and if you set serveroutput off
you wouldn't see anything. (Edit: this old AskTom thread talks about this behaviour too).
It isn't clear why you're trying to change the exception type after you've caught it. The only reason I can see to do that would be to get the behaviour you have, where any error gives you an empty result set rather than an exception you have to handle. If that isn't what you want to happen then you shouldn't do that, to state the obvious a bit. If it is then you'd need to look for the dbms_output
message from the Java side.
But I don't see why you would want to do that in preference to just reraising the original exception:
when others then
dbms_output.put_line(SQLCODE||' '||sqlerrm );
raise;
... or since the dbms_output
isn't always going to be visible to the client, just not catching others
at all. It seems a bit pointless and counterintuitive to catch and squash an exception when you want the (Java) client to see it.
The exception on the Java side would then be something like (from e.getMessage()
):
ORA-00904: "WRONG_COLUMN": invalid identifier
ORA-06512: at "SCHEMA.MYTEST", line 23
Perhaps you want to hide the PL/SQL stack trace and just show a single line of the first error encountered, but it seems like it would be rather more useful to keep that information so you can track down the error.