RE: Interesting Exploit in PL/SQL
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <Jacques.Kilchoer@xxxxxxxxx>, "oracle-l" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 30 Nov 2006 14:12:40 -0500
Playing devil?s advocate (as I agree with the notion that ?when others then
null? is a suspect combination of words to occur), the poster could be
implying that when there is a simple way to check for the remaining errors
it may in fact be easier overall and possibly faster to let the procedure
fly through without notice of errors and then separately check which objects
remain in the unchanged state.
So the special case is then: when I want to change everything away from X,
change everything away from X ignoring and not even reporting failures, then
run a comprehensive report for exceptions.
So in fact you really don?t care which ones fail because you?ll be checking
for all failures after completion. Correcting individual errors may require
some intervention or an ?eyes wide open? knowledge of the failures.
This special case is only reasonable when there is an easy (aka cheap) way
to check comprehensively for the failures.
Seems to me that logging the errors would be an alternative, but that would
require an autonymous commit, so when specifically used for this purpose and
requiring maximum speed I?m thinking it is a valid exception.
Regards,
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On
Behalf Of Jacques Kilchoer
Sent: Thursday, November 30, 2006 1:34 PM
To: oracle-l
Subject: RE: Interesting Exploit in PL/SQL
So if your procedure was only able to enable auditing on half the objects in
the database, and failed to enable auditing on the other half, you didn't
care? I guess in this case it would make sense. But then the other option
would be to not run the procedure at all, if you didn't care which objects
had auditing enabled.
_____
De : Stefan Knecht [mailto:knecht.stefan@xxxxxxxxx]
Envoyé : jeudi, 30. novembre 2006 02:18
À : Jacques Kilchoer
Cc : oracle-l
Objet : Re: Interesting Exploit in PL/SQL
There are situations where you can use when others then null; - and it even
makes sense.
For example, we've had a procedure to enable / disable auditing on all
objects in a database. To avoid having to filter out all possible errors
due to the huge number of different objects (and especially the sys objects)
we used a construct like
begin
noaudit all on x.y;
exception
when others then null;
end;
If the noaudit fails for whatever reason (we just don't care why here), we
simply go on to the next object. That was perfectly fine for this case.
Stefan
On 11/29/06, Jacques Kilchoer < Jacques.Kilchoer@xxxxxxxxx
<mailto:Jacques.Kilchoer@xxxxxxxxx> > wrote:
What does this below mean? Are you trying to say "when you MUST make sure
that the program NEVER stops, regardless of whatever errors I encounter" ?
If so, I can't imagine why someone would want to do that.
-----Message d'origine-----
De : oracle-l-bounce@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx>
[mailto: oracle-l-bounce@xxxxxxxxxxxxx
<mailto:oracle-l-bounce@xxxxxxxxxxxxx> ] De la part de Nuno Souto
Envoyé : mercredi, 29. novembre 2006 00:26
Cc : Oracle-L Freelists
Objet : Re: Interesting Exploit in PL/SQL
4- If you don't know what error can be generated but you MUST run the code
nevertheless, then you MUST use WHEN OTHERS THEN NULL. Or pay the price of
a temp table to keep all possible return codes. Otherwise your code won't
run. No, I will NOT recommend coding exceptions for 20000 possible error
returns!
So, rather than embark in yet another crusade of calling anyone who doesn't
follow the fad an incompetent by nature, can we just for once address the
problem at the root?
And ask Oracle to fix it first rather than blame everyone else for it?
--
Cheers
Nuno Souto
in windy Sydney, Australia
dbvision@xxxxxxxxxxxx <mailto:dbvision@xxxxxxxxxxxx>
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
