There are parameterized error messages in Oracle database. For example, there is 01919, 00000, "role '%s' does not exist" in oraus.msg.
If one issue some nonsense GRANT ... TO ... %s is substituted by this nonexistent privilege.
It is possible to raise exception -1919 and supply some string to %s?
Code:
not_system_privilege EXCEPTION;
PRAGMA EXCEPTION_INIT(not_system_privilege, -01919);
.......
RAISE not_system_privilege;
produces only ORA-01919: role '' does not exist message.
The purpose of user-defined exceptions is that we can trap specific exceptions in the exception section of our PL/SQL program and handle them elegantly. For instance, if we put some flesh around your code snippet....
create or replace grant_priv
( p_priv in varchar2
, p_grantee in varchar2 )
is
not_system_privilege EXCEPTION;
PRAGMA EXCEPTION_INIT(not_system_privilege, -01919);
begin
execute immediate 'grant '||p_priv||' to '||p_grantee;
exception
when not_system_privilege then
raise_application_error(-20000, p_priv||' is not a real privilege', true);
when others then
raise;
end;
We can put anything in the EXCEPTIONS section. Log the error in a table or file, raise alerts, whatever. It is good practice to propagate the exception upwards: only the toppermost layer of the callstack - the user-facing layer - shouldn't hurl exceptions.
An observation - it looks like you can use utl_lms.format_message for C-style printing - wish I'd known this earlier (as would have saved writing it). Seems to be Ora10 and above only.
begin
dbms_output.put_line(
utl_lms.format_message(
'A %s is here and a %s is there and a %s too','Giraffe','Lion','Spider'));
end;
I can't see any way to meet the OPs requirement - to RAISE a system-level exception and substitute in the right parameter.
However, if you can live with using a different exception number, you could write your own exception handling procedure that could
a) take in the serial of the required exception
b) use utl_lms.get_message to retrieve the text
c) use format_message to substitute in the parameters
d) raise a user defined exception using the generated text
The problem is that this would not work if your calling system expects an ORA-01919.
Related
I'm creating a process in Oracle Apex 5.0. Please help me to get rid some duplicate error codes.
I've multiple conditions where error needs to be thrown. But at the end of the block when I write Exception block with sqlerrm it throws error code two times.
begin
-----------------------------
-----some code statements----
-----------------------------
if (<condition 1>) then
-----------------
----some code----
-----------------
elsif(<condition 2>) then
raise_application_error(-20001, '----statement1----');
elseif(<condition 3>) then
raise_application_error(-20002), '----statement2----');
end if;
exception
when others then
raise_application_error(-20003, SQLERM);
end;
Now, if any error occurs because of those IF statements then result will look like
ORA-20001: ORA-20003: ----statement1----.
But I need to show like, for example
ORA-20001: ----statement1----
How can I get it? Please help me to find what should I do here.
RAISE_APPLICATION_ERROR throws a bespoke error. But like any other exception that our application might hurl it is trapped by the local exception handler.
Your exception handler is raising a new bespoke exception for any and all errors. Don't do this. You can easily fix your problem by removing the exception block. All exceptions will be propagated up the calling stack without any modification.
begin
-----------------------------
-----some code statements----
-----------------------------
if (<condition 1>) then
-----------------
----some code----
-----------------
elsif(<condition 2>) then
raise_application_error(-20001, '----statement1----');
elseif(<condition 3>) then
raise_application_error(-20002), '----statement2----');
end if;
end;
Alternatively, you could employ user-defined exceptions.
declare
x_condition2 exception;
x_condition3 exception;
begin
-----------------------------
-----some code statements----
-----------------------------
if (<condition 1>) then
-----------------
----some code----
-----------------
elsif(<condition 2>) then
raise x_condition2;
elseif(<condition 3>) then
raise x_condition3;
end if;
exception
when x_condition2 then
raise_application_error(-20001, '----statement1----');
when x_condition3 then
raise_application_error(-20002, '----statement2----');
end;
You still needn't bother with WHEN OTHERS unless you have some specific processing you want to apply to all errors (such as logging them). There is no value in just re-raising an exception in the handler section because propagation happens by default.
#Deep asked
cant we make both exceptions?
Yes we can do this:
declare
x_condition2 exception;
PRAGMA EXCEPTION_INIT(x_condition2,-20001);
x_condition3 exception;
PRAGMA EXCEPTION_INIT(x_condition3,-20002);
….
Declaring an exception creates a bespoke exception. PRAGMA EXCEPTION_INIT associates a bespoke error number with that exception. I wouldn't bother doing this in an anonymous block, because we don't get much value from it. We would still need to execute raise_application_error to return our tailored error messages.
Where pragma exception_init becomes really useful is when we are passing exceptions between program units. Exceptions which need to be handled by calling programs should be declared in package specs. Using pragma exception_init means that we can identify errors using sqlcode which can be helpful for tasks such as looking up standard error messages from a table, providing user help text, etc.
Suppose I have a procedure as follows:
PROCEDURE proc_name (args)
IS
-- declarations
...
BEGIN
-- code
...
EXCEPTION
WHEN an_error THEN
--error handling code
....
WHEN another_error THEN
-- error handling code, identical to the one for an_error
...
WHEN others THEN
---generic error handling code`
....
END;
Ideally, I would like to be able to catch both an_error and another_error in the same WHEN clause, since their handling is identical.
Is this possible in Oracle? If not, what are other possibilities to avoid code duplication?
Yes you can.
You can use OR conditions between the exceptions so
EXCEPTION
WHEN an_exception
OR another_exception
THEN
handle it here;
END;
See The Docs for more details on exception handling.
Yes.
But not for OTHERS exception. It can not be merged with another exception.
I am running a method (the method name is sent by the end user) using dynamic PL/SQL (ex: EXECUTE IMMEDIATE).
When the method signature does not match the error ORA-06550 is raised (PLS-00306 is also mentioned in the stack).
I need to raise a custom message when the method signatures does not match with the required signature.
So I catch ORA-06550 inside the PL/SQL exception block and raise an error. Only to notice that ORA-06550 is raised for any invalid PL/SQL code (including method signature mismatch)
My Questions
What is the difference between ORA- type messages and PLS- types ones. Can't one catch PLS- type messages (ex: PLS-00306) like they do catch ORA- type ones (ex: ORA-06550). If possible how?
If not possible how to catch signature mismatches? (apart from running a query against USER_ARGUMENTS)
PLS-errors are PL/SQL compiler's compilation errors and can't be directly caught run-time as they are wrapped with ORA-errors.
If the compilation error is triggered by static PL/SQL the unit under compilation is created as invalid and execution of the unit triggers PLS-00905 (wrapped with ORA-06550).
If the compilation error is triggered by dynamic PL/SQL the unit under compilation is created without errors as dynamic PL/SQL is not checked during compilation. Instead the error is raised run-time when the unit is executed and can be caught but only ORA-code, not PLS-code. If you have do something based on PLS-code process the error stack string:
create or replace function get_custom_error(p_pls_code in varchar2) return varchar2 is
begin
return
case p_pls_code
when 'PLS-00201' then 'this is my custom error code'
else 'unknown PLS error code'
end;
end;
/
show errors
create or replace procedure foo is
plsql_compilation_error exception;
pragma exception_init(plsql_compilation_error, -6550);
v_a number;
begin
dbms_output.put_line('foo started');
execute immediate 'begin bar; end;';
dbms_output.put_line('foo ended normally');
exception
when plsql_compilation_error then
declare
v_pls_error_code constant varchar2(20) :=
regexp_substr(dbms_utility.format_error_stack,
'(PLS-[[:digit:]]+):', 1, 1, '', 1);
begin
dbms_output.put_line(get_custom_error(v_pls_error_code));
end;
end;
/
show errors
Execution example:
SQL> exec foo
foo started
this is my custom error code
PL/SQL procedure successfully completed.
SQL>
All Oracle error codes are listed and explained in Oracle Database Error Messages.
1) The difference between ORA and PLS is which engine raised the exception. Error on the top of error stack shows general error. Deeper errors provides more and more details. Like ORA-06550 happened because of PLS-00306
2) In any potentially dangerous place you should add BEGIN…EXCEPTION…END. To differentiate any ORA error you can declare exception in parent block and use PRAGMA directive to link it with error code.
begin
…
begin
…
execute immediate …
exception
when …
end;
…
end;
I am trying to drop the queue using following command:
EXECUTE DBMS_AQADM.DROP_QUEUE (queue_name => 'ORDVAL_QUEUE');
It is working fine but i want to put a check if queue does not exist and i execute above command thn it should not throw an error or exception.
I m using this but din't got my target :
BEGIN
EXECUTE IMMEDIATE 'DBMS_AQADM.DROP_QUEUE (queue_name => "ORDVAL_QUEUE")';
EXCEPTION
WHEN OTHERS THEN
null;
END;
It executes fine but does not drop queue.
I haven't used queues before, but this should help:
Add a BEGIN and END to the execute immediate, to use dynamic PL/SQL instead of dynamic SQL.
Use two single quotes instead of a double quote.
Catch specific exceptions when possible, avoid OTHERS. This was catching and ignoring unexpected exceptions.
Not shown below, but perhaps it would be better to check for the existence of the queue in ALL_QUEUES instead?
DECLARE
QUEUE_DOES_NOT_EXIST EXCEPTION;
PRAGMA EXCEPTION_INIT(QUEUE_DOES_NOT_EXIST, -24010);
BEGIN
EXECUTE IMMEDIATE
'BEGIN DBMS_AQADM.DROP_QUEUE (queue_name => ''ORDVAL_QUEUE''); END;';
EXCEPTION WHEN queue_does_not_exist then
dbms_output.put_line('Test to see if exception was thrown');
END;
/
I want to know about error handling in PL/SQL. Can anyone help me to find brief description on this topic?
Every block can have an exception handler. Example:
DECLARE
/* declare your variables */
BEGIN
/*Here is your code */
EXCEPTION
WHEN NO_DATA_FOUND THEN
/* HAndle an error that gets raised when a query returns nothing */
WHEN TOO_MANY_ROWS THEN
/* HAndle the situation when too much data is returned such as with a select-into */
WHEN OTHERS THEN
/* Handle everything else*/
END;
This link will tell you more: http://download.oracle.com/docs/cd/B13789_01/appdev.101/b10807/07_errs.htm
That link will show you more detail than I did, as well as examples on how to create your own exception names.
One item that always trips me up is that if you have a function and you fail to return a value in the exception handler, an exception gets thrown in the calling function. Not a big deal but I always seem to forget that one.
The Oracle article referenced in the other answer is well worth reading.
A couple of extra things to throw in - catching a PL/SQL exception loses the error stack - i.e. the information about exactly which line raised the exception.
This can make it difficult to debug blocks of code that contain multiple places that could raise the same exception (i.e. if you have more than one SQL statement that could return NO_DATA_FOUND). One option here is to log the full error stack as part of your exception handler.
EXCEPTION
WHEN TOO_MANY_ROWS THEN
myLogger('Some useful information',DBMS_UTILITY.FORMAT_ERROR_STACK);
END;
If you do need to catch exceptions, keep your exception handling as local as possible to the point you want to catch, and only use WHEN OTHERS in the last resort.
You can also 'do something and re-raise the same exception'
EXCEPTION
WHEN TOO_MANY_ROWS THEN
closeSmtpConnection;
RAISE;
END;
One of the most useful features is the ability to name and catch Oracle SQL internal exceptions.
DECLARE
recompile_failed EXCEPTION;
PRAGMA EXCEPTION_INIT (recompile_failed,-24344);
BEGIN
. . . . . .
EXCEPTION
WHEN recompile_failed THEN
emailErrors(pObjectType,pObjectName);
END;
The flipside to this is the ability to raise user defined 'SQL' exceptions
RAISE_APPLICATION_ERROR(-20001,'my text')
This is the only way to propagate user defined text to a calling application, as user-defined pl/sql exceptions do not cross the 'scope' boundary.
Unfortunately, despite the documentation saying that the range -20000 to -20999 is available for user-defined exceptions, some of the Oracle extension packages use these serials, so you cannot depend on serial alone to identify an error in the calling language.
(Most people tend to wrap RAISE_APPLICATION_ERROR in other code to also log the error, and often to derive the error text from a table)
One trick I've found useful is to create a package with 'stateful' variables in the package body, and simple setter and getter functions. Unlike database updates, information in packages is NOT rolled back on error.
At the point of error, set information in your package, then retrieve it using getters in your calling language, to construct a 'native' exception.
As for user-defined pl/sql exceptions - these can be useful in local code, but in many cases they can be avoided by using a different control structure (i.e. avoid using them as an alternative GOTO).
Creating global exceptions on package headers, to specify the possible exceptions a package may return seems like a good idea, but the end result is that your calling code ends up with having to handle every potential exception that could be cast in any of the underlying packages.
Having gone down this route myself in the past, I would now recommend against it - make packages self-contained and either use RAISE_APPLICATION_ERROR or pass back errors as text.