Error Handling in Forms

Question

Dear all,
we are using oracle developer suite 10g r2 with oracle database 10g r2 against windows server 2003.
Error handling is a very big issue.
i try to do the following, just correct me, or make the trigger more efficient.
i face unexpected messages, like a message two time displayed, sometime important message never displayed.
i just set the :system.message_level =20 in the when-new-form-instance trigger.
and create on-error trigger like below
declare
errcode number:=error_code;dbmserrcode number;dbmserrtext varchar2(200);
formtxt varchar2(200);
errtype varchar2(3);
begin
--------- user defined database exceptions errors raised by --RAISE_APPLICATION_ERROR
IF DBMS_ERROR_CODE in (-20738,.......) then
raise form_trigger_failure;
end if;
if error_code=50017 then
message('duration must be between 0 and 23');message(' ',no_acknowledge);
raise form_trigger_fialure;
elsif
error_code=40202 then
clear_message;
message('please provide the required fields.');message(' ',no_acknowledge);
raise form_trigger_fialure;
elsif error_code=50022 then
clear_message;
message('time must be in the correct format.');message(' ',no_acknowledge);
raise form_trigger_fialure;
end if;
if error_code in (40509,40508) then
dbmserrcode:=dbms_error_code; dbmserrtext:=dbms_error_text;
if dbmserrcode=-1438 then
clear_message;
message('your number is too large.try again.');message(' ',no_acknowledge);
raise form_trigger_fialure;
elsif dbmserrcode=-1400 then
clear_message;
message('your forgot to provide a value.try again.');message(' ',no_acknowledge);
raise form_trigger_fialure;
elsif dbmserrcode=-2291 then
clear_message;
message('header is not found for this insertion.');message(' ',no_acknowledge);
raise form_trigger_fialure;
elsif dbmserrcode=-1 then
clear_message;
message('record already exists');message(' ',no_acknowledge);
raise form_trigger_fialure;
else
clear_message;
message(error_code||' : '||error_text);message(' ',no_acknowledge);
raise form_trigger_fialure;
end if;
else
clear_message;
message(error_code||' : '||error_text);message(' ',no_acknowledge);
raise form_trigger_fialure;
end if;
exception
when others then
if dbms_error_code=-20738 then
clear_message;
message('Error: absent or later record errror from the database trigger.);
raise form_trigger_failure;
elsif .....
esle
clear_message;
message(error_code||' : '||error_text);message(' ',no_acknowledge);
raise form_trigger_fialure;
end if;
end;any suggession?
Regards

Answer 1

i must come with a plsql code which handle every error and suppress unnecessary messages.Good luck with that. No matter how well thought out or planned, you're not going to be able to take all scenarios into account. The design of an exception handler takes time to address all possible scenarios you want handled and even then, you're not likely to handle every situation in the beginning.
could we implement the oracle ebusiness error handling procedures here in our application?if yes, then where could we find that procedure?>
I've dug through that code and it is not a thorough as you think it is. It handles specific situations and then defaults the rest. It is a good model for your own exception handler, however. That is what I used it for. :) I don't recall which library it is in, but I'll look around and if I find it, I'll post it.
I agree with Andreas's comment...
Simply remove your ON-ERROR-trigger, then you have a default. That's nothing better or worse than what apex has.I'm not too familiar with Apex; I've worked with it, but it's been a little while. Even with Apex, you're going to have to develop a customized Exception Handler so more intuitive or application specific messages are displayed in response to an exception.
As to Andreas's comment...
For your own error-handling... The "simplest" way in my eyes is create your own error-table where you have appropiate columns for the error-code and the error-type (FRM,ORA,Whatever), then in your ON-ERROR-trigger read the appropiate record from that table and show the error. You could also have a flag in your table which decides what to do with a specific error (Show as Message, Show as Alert, Don't show at all) and react accordingly.This is exactly what we implemented in our application. We created a set of tables that contain all of the Oracle Runtime errors and their attributes (Error Type, Severity Level, etc). Then we wrote a standard On-Error trigger that is subclassed to all of our forms that calls a Library "On_Error" package. This package evaluates the exception raised, compares it to the database entry for the error and then displays an appropriate message depending on the Severity Level, Error Type (ORA or FRM) and Message Type (Informational, Error, Caution) and we display the message in either the Status Bar, Note Alert, Caution Alert or Stop Alert or it is supressed. If an error is not found in the table, then it is displayed in a Stop Alert as an "Unhandled Exception." The second table I mentioned contains all of the messages used by our application and is cross referenced with the table that contains the Oracle messages. By simply assigned one of our messages to an Oracle message - our package will display our message instead of the default Oracle Message. Yes, this took sometime to build and test and once implemented, we spent another couple of months perfecting it, but now it is pretty solid and we haven't had to modify it in over a year.
While this level of complexity may be overkill for your application, it does offer the greatest flexibility in the long-run. Also, if your application must support multiple languages, having all of your messages in a table make internationalization extremely easy. :)
The point of all this, is that no matter which system you use (Forms, Apex, or Java) you will still need to invest some time into designing an Excpeiton Handling method for your application and then implement it accross the application. This is not something you can develop in a short period of time and it will not be perfect in the beginning. However, in the long-run, you will be happy you spent the time up-front to build a flexible and robust Exception Handling system.
Craig...