Exception handling in BADI
Hi,
I am implementing a BADI in the BP transaction on the R/3 side.
For a certain select statement in the BADi, I am doing a sy-subrc <> 0 check, and if it is not equal to 0, I need to raise an exception.
I am raising an exception of type E. The popup comes on the screen, and once I hit continue, the transaction stops and is in the display mode.
Now, the problem occurs, if I try and make any change on the transaction screen, after the error pops up.
As soon as I try and make any change on the screen, the transaction dumps.
My requirements are that if certain checks are not valid, user should get an error message, asking to enter valid data, and he should be able to make change on the transaction screen to enter the valid data.
How can I do this? Any help in this regard would be highly appreciated.
Maninder
Hi Suresh,
In some cases we can use particularly while trying to change some data. But in case of creation certainly errpr type "E" is not allowed.
In that case Maninder can use error type "W".
For Package BUPA you have message classes defined as :
BUR
BUPA_STATUS
R1
R11
Code :
IF SY-SUBRC <> 0.
MESSAGE E001(BUR) WITH 'TEXT'.
ENDIF.
Regards,
Lanka
Similar Messages
-
Exception Handling Concept Gone Bad!!
Okay, this is by far the most embarrassing hack of code I've done thus far . . . but it works. I am trying to run a select where if there is no data or null returned, place it into the value "v_pidm', and then let the action occur. Simple enough, right? Wrong! A select that return no data which is using a 'into' function is an exception . . . "no data found." Oracle sends this to the exception block as it should. Okay, I don't want to stop and start my script a million times, there I added an sub Begin/End with an exception to handle the say error and perform an insert. I know you shouldn't use an exception state for inserts another than capturing errors . . . you know bad practices and all. Any ideas as how to better handle the select statement that should regularly return no data? I was thinking about some along the line of nvl(v_pidm, 0) or something, but I am getting errors.
set serveroutput ON SIZE 1000000
set heading off
set feedback off
set trimspool off
set echo off
set pagesize 0
set termout on
Declare
error varchar(255);
v_pidm number(8);
Begin
Begin
select distinct saraatt_pidm
into
v_pidm
from saraatt, saradap
where saraatt_appl_no = SARADAP_APPL_NO
and saraatt_term_code = SARADAP_TERM_CODE_ENTRY
and saraatt_pidm = 4;
Exception
when too_many_rows then
error := SQLERRM;
DBMS_OUTPUT.PUT_LINE(' %% Oracle Error! %% The select statement returned more than two rows ');
when no_data_found then
error := SQLERRM;
DBMS_OUTPUT.PUT_LINE('Select Returned No Data . . . Therefore Insert new record for ' || v_pidm );
v_pidm := -999;
when others then
error := SQLERRM;
DBMS_OUTPUT.PUT_LINE(' %% Oracle Error! %% An Error Occured ' || substr(error,5,20));
End;
DBMS_OUTPUT.PUT_LINE('Pidm: ' || v_pidm);
End;it would be better to just let the exception get propagated up so that you can see the full error stack.
Agrees fully with Justin
@Pr****
It took me a while as well, but in the end the best thing to do is avoid a WHEN OTHERS at all cost.
Once you resort to it, you're actually hiding some flaw(s), it might be design (it usually is)....or whatever, and the database covers up for t, and gets the blame.
And it's a pet-peeve of Tom Kyte for quite a while, and he wrote very good articles on it, do some readng on them:
http://google.com/search?q=site%3Atkyte.blogspot.com+%22when+others%22
Okay, I don't want to stop and start my script a million times, there I added an sub Begin/End with an exception to handle the say error and perform an insertYour example also doesn't seem to show the complete picture then?
I see no INSERT statement?
You have hidden your complete block structure, which makes it hard to guess what's going on/help you.
Perhaps you've nested your example in real life in another block, having it's own exception handler and so on...
I am getting errors.If you're getting errors and want some volunteers to help, then why not just post the full error message as well?
And your database version (the result of: select * from v$version; ) -
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.4Koen,
+(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 handler activity doesn't execute
I have an exception handler in my bounded task flow but it not always executes when an error is raised by some of the BTF activities.
In my application I'm having a problem with connections closed.
I don't know if the database, the firewall or who is closing connections but sometimes I get an error in the logs "oracle.jbo.JboException: JBO-29000: Se ha obtenido una excepción inesperada: java.sql.SQLRecoverableException, mensaje=Conexión cerrada" translation "oracle.jbo.JboException: JBO-29000: Un unexpected exception has been raised: java.sql.SQLRecoverableException, message=Closed connection".
That is bothering me specially because my task flow continues execution despite of the error. ADF opens the connection and then continues execution. This is fatal because previous updating in the entity objects is lost and the consequence is very bad.
Well, I have tried to insert an exception handler in my task flow in order to capture this errors and then stop execution of the task flow.
Currently, I'm more upset because of task flow continues execution after the connection closed error that for the error itself.
The problem is that sometimes the connection closed appears in the log window but the exception handler is not executed. Sometimes yes, some others no.
In order to test I'm forcing the error manually killing the sessions in the server.
Any help for any of both problems ? (1- BTF continuing execution after this error raising and 2-Why the exception handler doesn't always execute when a java error stack appears in the log window).
Thank you.this might be caused by a bug I found too causing eventhandlers not to work, the work round in your case would be:
blar blar blar
</variables>
<!-- start work round --><scope><!-- end work round -->
<faultHandlers>
blar blar blar
blar blar blar
</sequence>
<!-- start work round --></scope><!-- end work round -->
</process>
i.e. what I'm saying is that top level handler don't work since they are ignored by the engine because they are not in a scope. Try it and see.... -
Exception Handling for Array Binding
Hi
1)
I am using a Stored Procedure.
I am using array binding and if i am sending an array of count 10 to be inserted in a table and only 9 got inserted,i deliberatly inserted one errorneous record in array, the count returned by ExecuteNonQuery() is 10.Why ?
How can i come to know exact number of rows inserted in table, how can i use Output variables, because the array bind count is 10 so if i add an output parameter it gives error ArrayBind count is wrong....
2)
Is it possible to roll back all the inserts if error occurs in any of the insert by Oracle engine.What it does is it inserts all correct records and leaves the errorneous record and doesn't even throw any exception or any message.
Answer - This can be achieved by using OracleTransaction and don't use Exception handling in procedure otherwise there wont be any exception thrown by procedure which is necessary to detect if an error occured during insert.If you use exception handling OracleEngine will insert correct rows and leave errorneous record and return count of inserted + non inserted records which is wrong.
Please help.
Message was edited by:
user556446
Message was edited by:
user556446You'll need to encapsulate your validation within it's own block as described below:
-- this will die on the first exception
declare
TYPE T_BADDATA_TEST IS TABLE OF VARCHAR2(1000) INDEX BY binary_integer ;
tbt T_BADDATA_TEST ;
aBadTypeFound exception ;
begin
tbt(0) := 'a';
tbt(1) := 'b';
tbt(2) := 'c';
for idx in tbt.first..tbt.last loop
if tbt(idx) = 'b' then
raise aBadTypeFound ;
else
dbms_output.put_line(tbt(idx));
end if ;
end loop ;
end ;--encapsulate the exception area in a begin/end block to handle the exception but continue on
declare
TYPE T_BADDATA_TEST IS TABLE OF VARCHAR2(1000) INDEX BY binary_integer ;
tbt T_BADDATA_TEST ;
aBadTypeFound exception ;
begin
tbt(0) := 'a';
tbt(1) := 'b';
tbt(2) := 'c';
for idx in tbt.first..tbt.last loop
BEGIN
if tbt(idx) = 'b' then
raise aBadTypeFound ;
else
dbms_output.put_line(tbt(idx));
end if ;
EXCEPTION
WHEN aBadTypeFound THEN
dbms_output.put_line(tbt(idx) || ' is bad data');
WHEN OTHERS THEN
dbms_output.put_line('exception');
END ;
end loop ;
end ;
output:
a
b is bad data
c
***/ -
Hi there,
after playing a bit with external xml files provided by my
application i'm ready to go to the next topic on my ToDo-List.
How could one implement a good and stable technique for
exception handling? I'm talking about the interaction from spry to
our Web Framework which throws an error sometimes.
My current idea is that the server side framework could
return some kind of Error XML format which contains the exception
message and so on. This would require functions on client side to
precheck the server output.
Imho the best place for this is inside the XMLDataSet
constructor. When catching some bad XML file internal error
messages could be send using the already existing techniques OR by
providing an public function which then should be overriden by an
selfwritten one, e.g. to put it into my own `error box`.
Also, some kind of internal statemachine in XMLDataSet may
help a lot. That way each access to functions which aren't working
at the moment could be loggend and catched by an selfwritten
function.
I hope you get the idea,
what do you think?
Best regards,
SebastianBetter error handling and error handling hooks is on the list
of things to do.
The way I see it, there are several types of errors that can
occur:
1. Server returns valid XML, but it's XML that describes an
error instead of the data requested.
- I believe this is what Sebastian was mentioning. I was
actually thinking of allowing a hook for developers to catch and
handle this case and perhaps leverage the states mechanism to let
them change the dynamic region markup used to display the error
since the data references in this error XML would be different.
2. The server returns an error. (Invalid URL or Server Error)
- This could be handled with states, but we need to expose
some data references, or set the data set to contain a known data
set schema that would allow the designer to show more info about
the error.
3. The server returns XML but uses a mime-type that is not
understood by Spy or the XML parsing code built-into the browser.
- I believe it was Doug [?] that had a patch that *always*
forced the data set to try and parse the XML string in the response
if the response didn't contain an XML DOM. My one paranoia about
that is that the server could actually be returning something that
is not XML, in which we would still fail and perhaps choke
somewhere else. I need to do some testing in that area.
I was thinking perhaps we should add something to the
XMLDataSet constructor that allowed a user to specify mime-types
for formats they knew were XML, but didn't use one of the standard
XML formats.
4. The browser chokes on "not-well-formed" XML.
- This is an interesting problem. IE silently fails when the
parser chokes, but Mozilla creates an XML DOM tree that reports the
error which does *not* match the XML string from the request
response. I had to add code to spry to detect when this happens.
5. An exception is thrown during Spry processing of XML data.
- This will require more programming on our part to handle
more cases.
--== Kin ==-- -
How to handle the bad record while using bulk collect with limit.
Hi
How to handle the Bad record as part of the insertion/updation to avoid the transaction.
Example:
I am inserting into table with LIMIT of 1000 records and i've got error at 588th record.
i want to commit the transaction with 588 inserted record in table and log the error into
error logging table then i've to continue with transaction with 560th record.
Can anyone suggest me in this case.
Regards,
yuva>
How to handle the Bad record as part of the insertion/updation to avoid the transaction.
>
Use the SAVE EXCEPTIONS clause of the FORALL if you are doing bulk inserts.
See SAVE EXCEPTIONS in the PL/SQL Language doc
http://docs.oracle.com/cd/B28359_01/appdev.111/b28370/tuning.htm
And then see Example 12-9 Bulk Operation that continues despite exceptions
>
Example 12-9 Bulk Operation that Continues Despite Exceptions
-- Temporary table for this example:
CREATE TABLE emp_temp AS SELECT * FROM employees;
DECLARE
TYPE empid_tab IS TABLE OF employees.employee_id%TYPE;
emp_sr empid_tab;
-- Exception handler for ORA-24381:
errors NUMBER;
dml_errors EXCEPTION;
PRAGMA EXCEPTION_INIT(dml_errors, -24381);
BEGIN
SELECT employee_id
BULK COLLECT INTO emp_sr FROM emp_temp
WHERE hire_date < '30-DEC-94';
-- Add '_SR' to job_id of most senior employees:
FORALL i IN emp_sr.FIRST..emp_sr.LAST SAVE EXCEPTIONS
UPDATE emp_temp SET job_id = job_id || '_SR'
WHERE emp_sr(i) = emp_temp.employee_id;
-- If errors occurred during FORALL SAVE EXCEPTIONS,
-- a single exception is raised when the statement completes.
EXCEPTION
-- Figure out what failed and why
WHEN dml_errors THEN
errors := SQL%BULK_EXCEPTIONS.COUNT;
DBMS_OUTPUT.PUT_LINE
('Number of statements that failed: ' || errors);
FOR i IN 1..errors LOOP
DBMS_OUTPUT.PUT_LINE('Error #' || i || ' occurred during '||
'iteration #' || SQL%BULK_EXCEPTIONS(i).ERROR_INDEX);
DBMS_OUTPUT.PUT_LINE('Error message is ' ||
SQLERRM(-SQL%BULK_EXCEPTIONS(i).ERROR_CODE));
END LOOP;
END;
DROP TABLE emp_temp; -
What is the best way of Exception Handling
There are many ways to handle the exceptions of a program.
1: You could put every exception handler in the most upper abstract classes.
2: You could write a generic exception that handles a lot of things.
3: You could write exceptions handling for every class.
4: you could group the exception handling.
many, many more ways.
Question:
What is the best way to do this?There are many ways to handle the exceptions of a program.
1: You could put every exception handler in the most upper abstract classes.I woldn't do that always, a class may throw an exception if it's not able to handle it prperly, but it may, so it'll catch it. Throw Exception in abract supper clases only when you are sure the children must always throw the exception, not processing it.
2: You could write a generic exception that handles a lot of things.Bad idea, if you always throw an Exception no informtaion is provaided about whta happened, if you throw a NullPointerException and a NumberFormatException in one of your method I (for example) colud handle properly both problems, one likely to be a programming erros, so check my cod eagain, and the other like to be an user error in introduciong some data, so I wold ask him for the data again.
3: You could write exceptions handling for every class.Write exceptions handling for every class that needs it, throwing the exception if at that moment you don't know what to do with it and catching it if yes. Do not employ too many exception handling: execution of try catch blcks is slower than usuall code.
4: you could group the exception handling.I don't undestand this. What do youmean?
Question:
What is the best way to do this? In general thrwo an exception if the class dosen't know what to do with it, the class which uses yours will handle it. If your class can process the Exception, don't be too lazy and process it.
Employ exceptions always you need them but do not abuse; thay made the code execute slower because the VM machine must check if the exceotions occur.
abraham. -
Very simple exception handling
I know next to nothing about exceptions, I am still only in 3rd week of class, but I already ran into one.
I was using the Scanner Class, and the nextInt() function (method ?) to get some numbers to do simple math on. Program worked fine. But if I put a letter in when it asks for a number, it crashs to commandline with exception error. I just added text that told the user only to put in the right var type. Integers in this case. How would I make an exception handler ? is that right, exception handler ? that would simply say "wrong data type, please reenter", then ask again ? or something ?
Getting used to the forum here, bit different than I'm used to. Hope my question was clear.ok, I scanned through all and read thoroughly some of that. I have been working my way through the series as I can. we will be covering this in some detail later in the semester. That article (chapter?) is great, but it is too broad for me right now, I will post some code, and add some comments that try to do some of what I got from that article.
This is a stupid hello world type thing idid, we had worked with Scanner nextInt(), but not Scanner next, so I looked up how to get strings on my own... first week first prog i did anything on besides follow along :)
// Java Document
import java.util.Scanner; // uses Scanner Class
public class sparkle //main method
public static void main( String args[] )
Scanner input = new Scanner( System.in );
String name;
//so here I would add a try statement ?
System.out.print( "Enter Your Name:" );
name = input.next();
// and end it here ?
System.out.printf( "%s\t%s\t%s\n\t\t%s",
"***", "Java Programming!", "***", name);
// then I would put a catch here ? that tested to see if it was a string ?
//and if not then what ?
}maybe that is a bad example... I get that you have to wrap a block of code in a try statement, then you put catch statements, that see if the can do something about watever exception it is, but what do they do, the examples in that article use stuff way past where I am now... libraries I'm not familiar with to know what is happening. What does finally do ? what should happen instead, or what should happen either way ? I will go over more of that article, but most of it is meant to be read after I am further along... I think I am getting the basics though. Do I seem to be on the right track..?
I will post some more code about this later, I really don't expect to solve this overnight, but i know good exception handling hardens a program to faults, and provides stability. So I want to get a grasp of what to expect now. really, we wont be covering this in class for another month or two... but I want to prepare now, so I will be programming well by then.
Edited by: lord_midnight on Feb 15, 2008 4:02 PM -
Defensive programming vs exception handling
Hi
im new to java programming and having problems getting my head around defensive programming vs exception handling.
i've read in my uni books about design by contract and the idea of defensive programming but im having problems with it.
so say i write the code.
String container = //some value
if (container.equals.("")) // so if i am looking for a value and find a empty String
throw new // a custom exception i have made for this error.
else
//do whatever i had planned with a non-empty String
}is this Defensive programming or exception handling. Or am i complete of base.
thanksjverd wrote:
JustSomeGuy wrote:
Don't fall into the trap of saying "Meh, the exception will handle it". If you can forsee something easily being a problem, and it can be controlled, then control it. Save the exception handling for those things you don't forsee and those you can't control. I disagree. Or at least, I disagree with what I think you're saying.
For instance, if null is not a valid argument, then document it, and don't waste code defending against it. Either throw an explicit IllegalArgumentException, or let the NPE be thrown.
And absolutely under no circumstances should you ever write code that will deliberately lead to an exception, Eh? If an exceptional condition occurs, you should delibrately throw an exception. Consider if you will the following code snippet
import java.io.*;
class ExceptionExample {
public static void main(String[] args)
throws IOException {
if (args.length == 0) {
System.out.println("Must give filename as first arg.");
return;
FileInputStream in;
try {
in = new FileInputStream(args[0]);
catch (FileNotFoundException e) {
System.out.println("Can't find file: " + args[0]);
return;
int ch;
while ((ch = in.read()) != -1) {
System.out.print((char) ch);
System.out.println();
in.close();
} What I was saying in the first part is shown with the following part of the above code
if (args.length == 0) {
System.out.println("Must give filename as first arg.");
return;
} Would the exception handler that follows this peice of code have taken care of that? Sure! Would it be the best choice to just let the exception handler do it? No way no how!
It is easy to forsee someone forgetting or not realizing they need to add the filename as an arg and it can be controlled, so in this and most cases just like it the best choice is to either inform the user with a more specific statement than could be used in the exceptionhandler and do nothing or fix it yourself like for instance by using a default filename.
What I meant by deliberately throwing an exception can be illustrated with this small portion of my code above
int ch;
while ((ch = in.read()) != -1) {
System.out.print((char) ch);
} A -1 to mark the EOF is expected and reaching the EOF is expected. There is absolutely nothing abnormal about this, so it should not be handled by an exception. But far to often I have seen novice and especially "think they know it all novices" use an exception in place of exactly this. They know the file will end, they know they must do something about that, but instead of doing it right they just set it up so an exception will be thrown and they can just handle it in the exceptionhandler. This is what I meant by deliberately throwing exceptions, in that an exception must be thrown in order for their program to work as intended. Bad, very bad.
Now that I have provided an example and further clarified my position do you still disagree? I can't imagine you would, so if you do I would be very interested in getting some further insight into your reasoning.
JSG -
Hi,
I'm new to Java so I'm a little rusty with exception handling. Please help me with this portion of my code. I'm supposed to screen out the bad input by the user. The user has to enter a double value and not an illegal value, for example: 45ab would be unacceptable. I've tried this way but after entering a number, the program just exits. Thanks first for helping me out.
import javax.swing.*;
import java.io.*;
import java.text.*;
public class Circle {
public static double readDouble() {
boolean done = false;
String s;
double d=0;
while (!done) {
JOptionPane.showInputDialog("Enter a double : ");
System.out.flush();
try {
BufferedReader in = new BufferedReader (
new InputStreamReader(System.in));
s = in.readLine();
d = Double.parseDouble(s);
d = new Double(s).doubleValue();
done = true;
}catch (IOException e){
done = true;
}catch (NumberFormatException e1){
JOptionPane.showMessageDialog(null,"Error -- input a double -- Try again");
return d;
public static void area(){
double radius1;
double area;
radius1 = readDouble();
area = (radius1 * radius1) * Math.PI;
// Rounding the area value to 2 decimal places
NumberFormat nf = NumberFormat.getNumberInstance();
nf.setMaximumFractionDigits(2);
JOptionPane.showMessageDialog(null, "The area is " + nf.format(area));
// There are more code after this.Hello, I quickly wrote a possible solution to your problem, hope it will help you. (ICQ #28985387)
import javax.swing.*;
public class InputExample {
public static double getDouble() {
String input;
do {
input = JOptionPane.showInputDialog(null, "Enter a double", "Input", JOptionPane.QUESTION_MESSAGE);
} while(!validateDouble(input));
return Double.parseDouble(input);
private static boolean validateDouble(String input) {
double num = 0;
try {
if(input.length() == 0) {
JOptionPane.showMessageDialog(null, "Please enter a value", "Warning", JOptionPane.WARNING_MESSAGE);
return false;
num = Double.parseDouble(input);
} catch(NullPointerException exception) {
System.exit(0);
} catch(NumberFormatException exception) {
JOptionPane.showMessageDialog(null, "Not a double", "Warning", JOptionPane.WARNING_MESSAGE);
return false;
if (num < -Double.MAX_VALUE || Double.MAX_VALUE < num) {
JOptionPane.showMessageDialog(null, "Must be between\n" + (-Double.MAX_VALUE) + "\nand " + Double.MAX_VALUE, "Warning", JOptionPane.WARNING_MESSAGE);
return false;
return true;
} -
Good exception handling policy for Java web application
I'm looking for a good exception handling policy for Java web application. First I found this Java exception handling best practices - How To Do In Java which says that you should never catch the Trowable class nor use e.printStackTrace();
Then I found this Oracle page The Message-Driven Bean Class - The Java EE 6 Tutorial, which does just that. So now I'm confused. Is there a good page online for an exception handling policy for Java EE Web applications? I have a hard time finding one. I've read that you should not catch the Exception class. I've been catching it previously to make sure that some unknown exception doesn't slip through early in the loop and stops all other customers from executing later on in the loop. We have a loop which runs once a minute implemented using the Quartz framework. Is it OK if you just change the implementation to catch the RuntimeException class instead of the Exception class? We're using Java 7 and the Jetty Servlet Container.I'm looking for a good exception handling policy for Java web application.
If you have not done so I suggest you start by reviewing the several trails in The Java Tutorials.
Those trails cover both HOW to use exceptions and WHEN to use them.
This trail discusses the 'controversy' you mention regarding 'Unchecked Exceptions'
http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
Unchecked Exceptions — The Controversy
Because the Java programming language does not require methods to catch or to specify unchecked exceptions (RuntimeException, Error, and their subclasses), programmers may be tempted to write code that throws only unchecked exceptions or to make all their exception subclasses inherit from RuntimeException. Both of these shortcuts allow programmers to write code without bothering with compiler errors and without bothering to specify or to catch any exceptions. Although this may seem convenient to the programmer, it sidesteps the intent of the catch or specify requirement and can cause problems for others using your classes.
Why did the designers decide to force a method to specify all uncaught checked exceptions that can be thrown within its scope? Any Exception that can be thrown by a method is part of the method's public programming interface. Those who call a method must know about the exceptions that a method can throw so that they can decide what to do about them. These exceptions are as much a part of that method's programming interface as its parameters and return value.
The next question might be: "If it's so good to document a method's API, including the exceptions it can throw, why not specify runtime exceptions too?" Runtime exceptions represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way. Such problems include arithmetic exceptions, such as dividing by zero; pointer exceptions, such as trying to access an object through a null reference; and indexing exceptions, such as attempting to access an array element through an index that is too large or too small.
Generally don't catch an exception unless you plan to HANDLE the exception. Logging, by itself is NOT handliing.
First I found this Java exception handling best practices - How To Do In Java which says that you should never catch the Trowable class nor use e.printStackTrace();
That article, like many, has some good advice and some poor or even bad advice. You get what you pay for!
I've read that you should not catch the Exception class.
Ok - but all that does is indicate that a problem of some sort happened somewhere. Not very useful info. Java goes to a lot of trouble to provide specific exceptions for specific problems.
I've been catching it previously to make sure that some unknown exception doesn't slip through early in the loop and stops all other customers from executing later on in the loop.
If the exception is 'unknown' then maybe it NEEDS to 'stop all other customers from executing later on in the loop'.
That is EXACTLY why you don't want to do that. You need to identify which exceptions should NOT stop processing and which ones should.
Some 'unknown' exceptions can NOT be recovered and indicate a serious problem, perhaps with the JVM itself. You can NOT just blindly keep executing and ignore them without risking data corruption and/or the integrity of the entire system Java is running on.
Is it OK if you just change the implementation to catch the RuntimeException class instead of the Exception class? We're using Java 7 and the Jetty Servlet Container.
No - not if you want a well-behaved system.
Don't catch exceptions unless you HANDLE/resolve them. There are times when it makes sense to log the exception (which does NOT handle it) and then raise it again so that it gets handled properly later. Yes - I know that is contrary to the advice given in that article but, IMHO, that article is wrong about that point.
If you have ever had to maintain/fix/support someone else's Java code you should already understand how difficult it can be to find WHERE a problem occurs and WHAT the exact problem is when exceptions are not handled properly. -
EDN Mediator exception handling
Hi All,
I am subscrbing to business events through mediator.and then i am using the database adaptor to insert the data into a table.
I want to implement exception handling for the events.The delivery policies for event in mediator is guaranteed.Howver i still see the oracle text as The event is guaranteed to be handed to the subscriber, but because there is no global transaction, there is a possibility that a system failure can cause an event to be delivered more than once. If the subscriber throws an exception (or fails in any way), the exception is logged, but the event is not resent.
Does the above statement menas that i will lose my business event data.I cannot afford to miss any business events in any case.So i would like to know if in guaranteed delivery of events if the subscriber gives an error , i want my events to be still stored in database and not give excpetion to the publisher.
Pls help its urgent
Regards.....I think it is clearly defined here -
http://docs.oracle.com/cd/E28280_01/dev.1111/e10224/obe_intro.htm#CHDIBHBE
guaranteed
Events are delivered to the subscriber asynchronously without a global transaction. The subscriber can choose to create its own local transaction for processing, but it is committed independently of the rest of event processing. This option incurs a lower cost than the one and only one option because there is only the trip to one queue (the main event queue). In addition, EDN does not attempt to resend an event (regardless of the backing store being AQ or JMS). If one or more subscribers fail to consume the event (while others succeed), those subscribers lose the message. In this respect, guaranteed delivery actually means best effort delivery; that is, it is not guaranteed that each subscriber definitely consumes the message.
So "Guranteed" is just a bad choice of word. It actually means "Best-Effort" so if you cannot afford to miss a single message then avoid using EDN in your solution.
Regards,
Anuj -
MC.9 and MCY1 and Exception Handling in (Logistics Inf. Sys)LIS
Hi,
I want the 'Valuated Stock Value" greater then or equal to zero (>=) appear in the MC.9 report. I can create 'Exception' in MCY1 but am unable to do so. Once I am in MCY1; I choose 'Requirements' then Key Figure 'Valuated Stock Value' then 'Type of condition' is 'Threshold Val. Anal.' is set to '> 0'. However, the report still displays zero values in MC.9. I don't want to display 'Valuated Stock Value' zero to be displayed on the report. Please help.
Thanks
NavedHey Chris,
I got the point for exception handling in weblogic 9.2. We ae using 9.2. It comes up with the concept of shared page flows which means all my unhandled exceptions are thrown to the shared page flow controller. There based on the type of exception, i can forward the request to appropraite page.
Thanks anywyas,
Saurabh -
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
29its 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
Maybe you are looking for
-
I NEED OVER ALL HARDWARE SUPPORT FOR PAVILION DV6-3043TX
I NEED OVER ALL HARDWARE SUPPORT FOR PAVILION DV6-3043TX, DISPLAY : FLASHING, HDD : SMART ERROR 301, KEY BOARD : UNSERVISEABLE, USB PORT : DISCONNECTED CONTINUOUSLY, THERMAL SHUT DOWN : RAPIDLY SHUTDOWN DUE TO INCREASE IN TEMP AS I M PERIODICLY CLEAN
-
How to start XML reports in Oracle Apps
Hi All, As im new to develop XML reports in Oracle Apps. And Im used to develop oracle reports. But i have a new requirement came and i need to develop new XML reports. I am using windows please let me know any software to be installed and how to reg
-
Table Linking Activities with Activity Journal
Hello All, I need to know the table link between the activity number and the details like material code, material description which is stored in the activity journal of the transaction type. Kind Regards Atul
-
When I try to burn a playlist itunes tells me it cannot find the cd burning software
-
il anyoane has encountered this "problem"... i have a small divergence with a bank and i need to print my call log as proof& i do not know how to download the call log from the phone. i can use an instruction at least how to print it. thank you very