Using WWSBR_API.ADD_ITEM raises exception ITEM_CREATION_ERROR

All,
i create a very simple procedure in the schema of the portal owner:
create or replace procedure test_insert_item is
l_item_nr number;
l_site_id number;
l_corner_id number;
l_type_id number;
l_type_caid number;
l_region_id number;
begin
l_site_id := 154;
l_corner_id := 6989;
l_type_id := 2;
l_type_caid := 0;
l_region_id := 5;
l_item_nr := wwsbr_api.add_item (
p_caid => l_site_id
, p_folder_id => l_corner_id
, p_display_name => 'my test item'
, p_type_id => l_type_id
, p_type_caid => l_type_caid
, p_region_id => l_region_id
, p_text => 'my own text'
commit;
end;
If i run this procedure in SQL*Plus as the Portal-owner, then the first time during a session the procedure raises the exception
WWSBR_API.ITEM_CREATION_ERROR. Each following time that i run the procedure it inserts the text item as expected.
How come? I checked for invalid object etc., but there are none.
Any ideas?
Thanks in advance!
Regards,
Bindert Glazema

I experimented a little bit further. If i change the procedure to:
create or replace procedure test_insert_item is
l_item_nr number;
l_site_id number;
l_corner_id number;
l_type_id number;
l_type_caid number;
l_region_id number;
begin
l_site_id := 154;
l_corner_id := 6989;
l_type_id := 2;
l_type_caid := 0;
l_region_id := 5;
l_item_nr := wwsbr_api.add_item (
p_caid => l_site_id
, p_folder_id => l_corner_id
, p_display_name => 'my test item'
, p_type_id => l_type_id
, p_type_caid => l_type_caid
, p_region_id => l_region_id
, p_text => 'my own text'
commit;
exception
when WWSBR_API.ITEM_CREATION_ERROR then
l_item_nr := wwsbr_api.add_item (
p_caid => l_site_id
, p_folder_id => l_corner_id
, p_display_name => 'my test item'
, p_type_id => l_type_id
, p_type_caid => l_type_caid
, p_region_id => l_region_id
, p_text => 'my own text'
commit;
end;
then no exception will be raised when i run the procedure the first time during a SQL*Plus session and still the item is inserted. The weird thing is, that when i call this procedure from a dynamic page:
<HTML>
<BODY>
<ORACLE>
begin
portal30.test_insert_item;
exception
when portal30.wwsbr_api.ITEM_CREATION_ERROR
then
htp.p('Item creation error');
end;
</ORACLE>
</BODY>
</HTML>
then the item is not inserted when the page is run, but the page shows 'Item creation error' instead. Does anyone have an idea why this doesn't work?
null

Similar Messages

Problem - Adding item using wwsbr_api.add_item

Hi, I´m using portal 10.1.2.0.2 and when I try to add an file using wwsbr_api.add_item, it returns me the following error "ORA-29532: Java call terminated by uncaught Java exception: java.lang.NullPointerException"
But It happens only when the file name has special caracter.
Anybody has any idea how to solve it?

You mentioned at the top of the thread that the region type had not been defined. I have not tried this in 10.1.4, but I know in previous versions if you programmatic ally added a item to an undefined region it didn't show up until that region was manually configured as an item region. The symptoms were as you describe -- nothing showed up in edit or view mode. As soon as the region was setup as a item region, the items appeared.
Roche's suggestion will establish if the item is even being created at all.
Rgds/Mark M.

ITEM_CREATION_ERROR when using wwsbr_api.add_item

308 on Sun Solaris :
Here is my simple code :
New_Master_Item_Id := wwsbr_api.add_item
( p_caid => 118,
p_folder_id => 14489,
p_display_name => 'title',
p_type_id => wwsbr_api.ITEM_TYPE_FILE,
p_type_caid => wwsbr_api.SHARED_OBJECTS,
p_region_id => 5,
p_file_filename => '/array_dd/oracle-IAS/portal30/images/voltimum_map_france.gif')
I'm getting the followgin exception :
ITEM_CREATION_ERROR
Note that my file resides on DB Unix machine. Read access is OK for all.
Any idea ?

Franck,
ik have a similar problem. I tried to execute the following code:
declare
l_item_nr number;
l_site_id number;
l_corner_id number;
l_type_id number;
l_type_caid number;
l_region_id number;
begin
l_site_id := 73;
l_corner_id := 1;
l_type_id := 2;
l_type_caid := 0;
l_region_id := 5;
l_item_nr := wwsbr_api.add_item ( p_caid => l_site_id
, p_folder_id => l_corner_id
, p_display_name => 'my test item'
, p_type_id => l_type_id
, p_type_caid => l_type_caid
, p_region_id => l_region_id
, p_text => 'my own piece of text'
commit;
end;
Unfortunately, i ran into the same exception as you did. The weird thing is that the exception is only being raised the first time that i execute this code during a session. If i execute the code multiple times, the text-item is indeed being inserted. You mentioned that you did something with the language of your content area. What exactly? And how does the language of the content area interfere with the creation of this text item?
Thanks in advance!!
Bindert Glazema

Wwsbr_api.add_item problems

Hi there,
I'm trying to use wwsbr_api.add_item to add content to a content area folder from a PL/SQL procedure invoked from SQL*Plus.
I'm having no luck...
For text items I keep getting WWSBR_API.ITEM_CREATION_ERROR exceptions.
I've also tried setting context of the PORTAL30 SSO user via WWCTX_API.SET_CONTEXT which seems to be working as it is not raising an exception.
My Content Area id = 93 (wwsbr_all_content_areas)
My test upload folder id = 3359 (wwsbr_all_folders)
BEGIN
wwctx_api.set_context(p_user_name => 'PORTAL30'
,p_password => 'PORTAL30');
v_master_item_id := wwsbr_api.add_item
(p_caid => 93
,p_folder_id => 3359
,p_display_name => 'TEST'
,p_type_id => 2
,p_type_caid => 0
,p_region_id => 5
,p_text => 'AUTOMATIC TEXT TESTING!'
v_master_item_id := wwsbr_api.add_item
(p_caid => 93
,p_folder_id => 3359
,p_display_name => 'TEST2'
,p_type_id => 1
,p_type_caid => 0
,p_region_id => 5
,p_file_filename => 'c:\temp\test.doc'
COMMIT;
EXCEPTION
END;
For Files I get file permission problems in SQL*Plus which I resolved for a specific file using
call dbms_java.grant_permission ('PORTAL30','java.io.FilePermission','c:\temp\test.doc','read');
commit;
but then I get the same wwsbr_api exceptions as per the text file! Also how would I set the permissions globally for a whole directory?
I've loaded the procedure into PORTAL30 and am running it as that user.
John

ok had a typo in my folder_id which didn't help - doh! Fixed that and text items would upload.
to fix the file permission issues you can reference either individual files or folders with a wildcard in dbms_java.grant_permission, i.e.,
call dbms_java.grant_permission ('PORTAL30','java.io.FilePermission','c:\temp\test.doc','read');
call dbms_java.grant_permission ('PORTAL30','java.io.FilePermission','c:\temp\*','read');
...that fixed it! Excellent!
Oh and if I'm executing the procedure from portal30 schema I don't need to use wwctx_api.set_context either...

Raise exception using CX_MAPPING_FAULT

Hi,
I want to raise an exception when an error occured in the ABAP mapping.I can be able to raise single message exception using the above one but I want to raise exception for all the messages from an error message internal table.I collect return codes and error messages into an internal table and want to display them in SXMB_MONI. Is it possible to raise multiple exceptions using CX_MAPPING_FAULT.
Thanks,
RP

Hi,
Refer,
http://help.sap.com/saphelp_nw04/helpdata/en/ba/e18b1a0fc14f1faf884ae50cece51b/content.htm
http://help.sap.com/saphelp_erp2005vp/helpdata/en/ba/e18b1a0fc14f1faf884ae50cece51b/content.htm
http://srikanth4xi.blogspot.com/
"Award points if helpful"
Regards,
Jayasimha Jangam

Re: Raising Exceptions Vs returning erro[Ref:C809787]

Hi Steve !
Probably the following explanation might help in resolving the issue raised by
you:
At a more abstract level, there is only one thing, i.e. the EVENT. According to
it's definition, an event is a relatively infrequent occurrence in one portion (lets
call it event raiser) of the application, which some other portion (or portions,
lets call them event handlers) (of the same application) are interested to respond
to it. Now there are two scenarios:
(A) Event raiser and Event handler(s) are being executed under different threads
of control (Asynchronous) and
(B) Event raiser and Event Handler(s) are being executed under same thread of
control (Synchronous).
So, Exception Handling belongs to scenario B where the method raising the
exception (Event Raiser or exception raiser) and the method handling it (Event
Handler or exception block) are under the same thread of control. More ever it has
to be insured that at a time only one handler (first the inner most one) receives
the message.
Forté provides a generic Event handling mechanism (Post Event and Event Loop) to
handle the scenario A (which is the more generic one). But it also provides a
specialized Event Handling mechanism (Raise Exception and Exception block) to
efficiently handle the relatively simple scenario B. Why I am saying that the later
is efficient because it won't be needing to register the event queue address of the
interested task (after all there is only one task involved) and put the event
message in queue.
Finally let me mentioned that it is just my view based on the understanding I
have and it may not be true. Only a person from forté can confirm it. I will really
appreciate if somebody correct and or refine it.
Wish a Very Very Happy New Year to all Forté Users
Regard,
Kailash.
[email protected] wrote:
I would agree with Eric entirely. Exceptions seem to me to be a much more
complete solution to the problem of error handling. A little bit of effort up
front in making clear the strategy for exception handling and specifying the
exceptions that can be raised by a class\method will provide an excellent method
for error handling.
In the case of ensuring exceptions are always handled, a top level handler for
GenericException will usually do the job, allowing you to write error
information out to logs, screen, etc, and then shut down gracefully.
The only issue I would raise with exceptions is that they are not propagated
outside an asynchronous task. If an exception is not handled within an
asynchronous, it will not propagate to the task that started that asynchronous
task. Forte provides return and exception events when starting asynchronous
tasks to cope with this, but it seems a shame to have one method of dealing with
errors (exceptions) for synchronous behaviour, and another (events) for
asynchronous behaviour.
Steve Elvin
Systems Developer
Frontline Ltd.
UK
Mark,
The problem with return codes is that there is an underlying assumption
that the receiver will always catch and interpret that error code. This
may or may not be good thing, depending on how you architect your
application. If, on the other hand, you want to ensure that an error is
always handled, if not by the receiver then by the Forte, Exceptions are
the way to go. To extend this mechanism further, I would subclass
GenericException and created my own error code attribute on that
subclass. That way the receiver has the choice of interpreting the
exception based on that error code, and wrapping it in a
MessageDialog/window or do the usual 'errormgr.showerrors()'.
Exceptions seem a more flexible approach to me. That is, if you can live
with the fact that by using it, you're violating the 'exceptions for
behavioral anomalies' software engineering principle !
Best wishes.
Eric Pereira
Forte Consultant
----Original Message Follows----
From: "Kallambella, Ajith" <[email protected]>
To: "'Mark Sundsten'" <[email protected]>, [email protected]
Cc: [email protected]
Subject: RE: Raising Exceptions Vs returning error codes
Date: Wed, 30 Dec 1998 08:52:39 -0500
Reply-To: "Kallambella, Ajith" <[email protected]>
Mark,
Identifying conditions where you would rather use an exception
to an error_code ( and vice-versa ) normally depends on
your application design. Usually exceptions
are used to handle behavioral anomalies which are
not expected during the normal course of execution of
the program, and which would affect the continuity of
your algorithm if ignored. Examples would be a fatal
error, a semantically invalid( but syntactically-valid
token ) etc.
Error_codes and return status's can be used to handle
anticipated and recoverable errors. Example would
be presentation layer validations. In any normal
UI system, the user is expected to make errors and it
would be annoying to throw an exception( and to handle
it ), every time user enters wrong data. A well
modeled client layer should not only handle
data-validation errors , but should be smart enough
to encourage users to input correct or
"near-correct" data. Examples could be
making use of look-up windows etc. Interestingly,
Express uses exceptions to handle data-validations.
As you see, exceptions fit well into your processing
logic where severity of damage caused by an error
is more. Where as error_codes fit well into presentation
logic( and some not-so-critical processing logic ) where
errors are usually recoverable and normal path of
execution can be easily restored.
Hope this helps. I would be very interested to hear
what others have to say.
Ajith Kallambella. M
Forte Systems Engineer,
International Business Corporation.
-----Original Message-----
From: Mark Sundsten [mailto:[email protected]]
Sent: Tuesday, December 29, 1998 2:10 PM
To: [email protected]
Cc: [email protected]
Subject: Raising Exceptions vs returning error codes
When dealing with error handling, I find myself struggling with the
choice
of
raising exceptions (and handling them) from the caller
vs returning an error code of somekind.
When would you want to use one over the other?
Should you always use exception handling?
Any discussion would be appreciated.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Hi Steve !
Probably the following explanation might help in resolving the issue raised by
you:
At a more abstract level, there is only one thing, i.e. the EVENT. According to
it's definition, an event is a relatively infrequent occurrence in one portion (lets
call it event raiser) of the application, which some other portion (or portions,
lets call them event handlers) (of the same application) are interested to respond
to it. Now there are two scenarios:
(A) Event raiser and Event handler(s) are being executed under different threads
of control (Asynchronous) and
(B) Event raiser and Event Handler(s) are being executed under same thread of
control (Synchronous).
So, Exception Handling belongs to scenario B where the method raising the
exception (Event Raiser or exception raiser) and the method handling it (Event
Handler or exception block) are under the same thread of control. More ever it has
to be insured that at a time only one handler (first the inner most one) receives
the message.
Forté provides a generic Event handling mechanism (Post Event and Event Loop) to
handle the scenario A (which is the more generic one). But it also provides a
specialized Event Handling mechanism (Raise Exception and Exception block) to
efficiently handle the relatively simple scenario B. Why I am saying that the later
is efficient because it won't be needing to register the event queue address of the
interested task (after all there is only one task involved) and put the event
message in queue.
Finally let me mentioned that it is just my view based on the understanding I
have and it may not be true. Only a person from forté can confirm it. I will really
appreciate if somebody correct and or refine it.
Wish a Very Very Happy New Year to all Forté Users
Regard,
Kailash.
[email protected] wrote:
I would agree with Eric entirely. Exceptions seem to me to be a much more
complete solution to the problem of error handling. A little bit of effort up
front in making clear the strategy for exception handling and specifying the
exceptions that can be raised by a class\method will provide an excellent method
for error handling.
In the case of ensuring exceptions are always handled, a top level handler for
GenericException will usually do the job, allowing you to write error
information out to logs, screen, etc, and then shut down gracefully.
The only issue I would raise with exceptions is that they are not propagated
outside an asynchronous task. If an exception is not handled within an
asynchronous, it will not propagate to the task that started that asynchronous
task. Forte provides return and exception events when starting asynchronous
tasks to cope with this, but it seems a shame to have one method of dealing with
errors (exceptions) for synchronous behaviour, and another (events) for
asynchronous behaviour.
Steve Elvin
Systems Developer
Frontline Ltd.
UK
Mark,
The problem with return codes is that there is an underlying assumption
that the receiver will always catch and interpret that error code. This
may or may not be good thing, depending on how you architect your
application. If, on the other hand, you want to ensure that an error is
always handled, if not by the receiver then by the Forte, Exceptions are
the way to go. To extend this mechanism further, I would subclass
GenericException and created my own error code attribute on that
subclass. That way the receiver has the choice of interpreting the
exception based on that error code, and wrapping it in a
MessageDialog/window or do the usual 'errormgr.showerrors()'.
Exceptions seem a more flexible approach to me. That is, if you can live
with the fact that by using it, you're violating the 'exceptions for
behavioral anomalies' software engineering principle !
Best wishes.
Eric Pereira
Forte Consultant
----Original Message Follows----
From: "Kallambella, Ajith" <[email protected]>
To: "'Mark Sundsten'" <[email protected]>, [email protected]
Cc: [email protected]
Subject: RE: Raising Exceptions Vs returning error codes
Date: Wed, 30 Dec 1998 08:52:39 -0500
Reply-To: "Kallambella, Ajith" <[email protected]>
Mark,
Identifying conditions where you would rather use an exception
to an error_code ( and vice-versa ) normally depends on
your application design. Usually exceptions
are used to handle behavioral anomalies which are
not expected during the normal course of execution of
the program, and which would affect the continuity of
your algorithm if ignored. Examples would be a fatal
error, a semantically invalid( but syntactically-valid
token ) etc.
Error_codes and return status's can be used to handle
anticipated and recoverable errors. Example would
be presentation layer validations. In any normal
UI system, the user is expected to make errors and it
would be annoying to throw an exception( and to handle
it ), every time user enters wrong data. A well
modeled client layer should not only handle
data-validation errors , but should be smart enough
to encourage users to input correct or
"near-correct" data. Examples could be
making use of look-up windows etc. Interestingly,
Express uses exceptions to handle data-validations.
As you see, exceptions fit well into your processing
logic where severity of damage caused by an error
is more. Where as error_codes fit well into presentation
logic( and some not-so-critical processing logic ) where
errors are usually recoverable and normal path of
execution can be easily restored.
Hope this helps. I would be very interested to hear
what others have to say.
Ajith Kallambella. M
Forte Systems Engineer,
International Business Corporation.
-----Original Message-----
From: Mark Sundsten [mailto:[email protected]]
Sent: Tuesday, December 29, 1998 2:10 PM
To: [email protected]
Cc: [email protected]
Subject: Raising Exceptions vs returning error codes
When dealing with error handling, I find myself struggling with the
choice
of
raising exceptions (and handling them) from the caller
vs returning an error code of somekind.
When would you want to use one over the other?
Should you always use exception handling?
Any discussion would be appreciated.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

ECL Viewer 5 raise exceptions viewing tif drawings

Hello all,
Bit of a strange one here that hopefully someone may be able to help me with...
We are (still) running 4.6C, on Ora 9.2.0.7 over Windows.
We are running 640 Gui patched to 24
We have deployed (in a failed attempt to stop the error I will describe below) ECL viewer 5.1.3.
Client machines are running XP with SP2
Error:
after entering MM03 and choosing Additional Data > Document Data we click on an attchment (doc type DRG) and choose to view via the display (glasses) icon. The tif file (which is copied into C:\temp) opens. many of the tif files (scanned drawings) have multiple pages so we move to the next page by clicking 'Navigation' > 'next'.
The problem is that after a seemingly random amount of clicks on to next pages a raise exception occurs. After the short dump it is no longer possible to view the document again as we get the error 'file c:\temp\xxxxx.tif cannot be created' and so the only way to view the drawing is either to access the file from the temp directory or completly log out of SAP and relog back in.
i have searched for notes and we were advised to deploy the 5.1.3 viewer which only seems to have made it worse because before the 5.1.3 deployment we were getting many short dumps but the user oddly didn't see the short dump on their screens - now 5.1.3 is in place the user now sees the short dump and calls the support desk very often.
Has anyone been unfortunate enough to have experienced this before or anyone got any brain waves????
yours thankful in advance and loosing the will to live,
Andy
ps here is the short dump extract:
                                                                                Error analysis
A RAISE statement in the program "CL_GUI_CFW====================CP " raised the
exception
condition "CNTL_ERROR".
Since the exception was not intercepted by a superior program
in the hierarchy, processing was terminated.
Short description of exception condition:
For detailed documentation of the exception condition, use
Transaction SE37 (Function Library). You can take the called
function module from the display of active calls.
How to correct the error
If the error occurred in a non-modified SAP program, you may be
able to find a solution in the SAP note system.
If you have access to the note system yourself, use the following
search criteria:
"RAISE_EXCEPTION"
"CL_GUI_CFW====================CP " or "CL_GUI_CFW====================CM00P "
"UPDATE_VIEW"
or
"CL_GUI_CFW====================CP " "CNTL_ERROR"
or
"SAPMMG01 " "CNTL_ERROR"
If you cannot solve the problem yourself, please send the
following documents to SAP:
1. A hard copy print describing the problem.
   To obtain this, select the "Print" function on the current screen.
2. A suitable hardcopy prinout of the system log.
   To obtain this, call the system log with Transaction SM21
   and select the "Print" function to print out the relevant
   part.
3. If the programs are your own programs or modified SAP programs,
   supply the source code.
   To do this, you can either use the "PRINT" command in the editor or
   print the programs using the report RSINCL00.

Hi Andy,
I would recommend you to upgrade to the latest available ECL Viewer version 6.
Please see SAP note 1083901.
Further please upgrade also your SAPGUI to the latest patch level as explained in note 164203. After this upgrade please un-install your ECL Viewer 5.1.3 by using one of the following mehtods:
Search for WebViewer2d.dll file. If it is present at more than one place then it means ECL Viewer is installed more than once without uninstalling the previous version (You can check the folders and should be able to see all the dll's for ECL Viewer such WebViewer3d.dll/Printing.dll etc to make sure that there is not only single file but the whole installation).
In this case:
A) Uninstall the version integrated with SAP GUI by using SAP Installation scripts. You need to uncheck the 'EAI Viewer' component in 'General Add-on' option.
B) Check add/remove program and if there is an entry like SAP Viewer, uninstall it.
After this search again, and you should not get WebViewer2d.dll file on machine. Now reinstall the latest Viewer. This should solve most of the issue related to inconsistencies.
Then install the latest ECL Viewer 6 and the issue should be solved.
Best regards,
Christoph

Error text missing in raising exception (In ABAP mapping)

Hi,
iam using ABAP Mapping for 1 interface.
Based on some condition i am raising exception with error text. When i executed this in SXI_Mapping_test it's showing the Error text. But when i execute the interface directly error text is missing in the Error details.
can any one figure out y its not coming..
regards
Kishore

Hi,
I think you need to write the error to mapping trace.
http://help.sap.com/saphelp_nw04/helpdata/en/ba/e18b1a0fc14f1faf884ae50cece51b/content.htm
Regards
Vijaya

Raising exceptions in PL/SQL

Hi Friends
I have the following code:
declare
var1....
var2....
cursor c1
begin
insert stmt;
update stmt;
update stmt;
for r1 in c1 loop
end loop;
end;
I will be having about 6-7 million rows every month to process. To raise exceptions, I am thinking of either of the following options:
Option 1_
declare
var1....
var2....
var3 exception;
var4 exception;
var5 exception;
cursor c1
begin
insert stmt;
update stmt;
IF SQL%NOTFOUND then
var3;
end if;
update stmt;
IF SQL%NOTFOUND then
var4;
end if;
for r1 in c1 loop
end loop;
IF SQL%NOTFOUND then
var5;
end if;
Exception
when var3 then blah blah
when var4 then blah blah
when var5 then blah blah
end;
Option 2_
declare
var1....
var2....
cursor c1
begin
insert stmt;
update stmt;
update stmt;
for r1 in c1 loop
end loop;
Exception
when others then blah blah
end;
In terms of performance, which option is better? And is there any better option?
Thanks....

In terms of performance, which option is better? And is there any better option?If you consider in terms of performance i think you cant find any difference in both ways.
But your both code does not do the same thing. They are entirely different. They are not the same.
For example, If your UPDATE statement fails with a Too many rows error what will happen.
In the first procedure the procedure will raise the error to the client. But in the second case the error is caught by the WHEN OTHERS block.
So now here the real thing is what you do in the WHEN OTHERS block. Do you suppress the error? Do you return NULL? What do you do, That is what matters.
Your Bla..Bla..Bla.. part in the EXCEPTION is very important. Most of them do mistake there.
WHEN OTHERS is a great feature. But it must be used properly. Its like a very sharp knife. If you dont use it properly there will be blood.

Raising Exceptions in WDA?

Hi,
   I want to know about raising exception in wda. Please explain in details.
Scenario: I have one input field as mandatory. if i click the button without filling that input field, self defined exception should raise. How to do this?
Thanks,
Gopi.

hi ,
place a UI message area in the RootElement Containeru cn make use of control wizard ( CONTROL + F7) to generate error or exception messages
select the radio button , generate messages and choose the method report_error_message
this code wud be automatically generated thru code wizard
* get message manager
DATA lo_api_controller     TYPE REF TO if_wd_controller.
DATA lo_message_manager    TYPE REF TO if_wd_message_manager.
lo_api_controller ?= wd_this->wd_get_api( ).
CALL METHOD lo_api_controller->get_message_manager
RECEIVING
    message_manager = lo_message_manager
* report message
CALL METHOD lo_message_manager->report_error_message
EXPORTING
    message_text              =   'Error_Text' " Give your error text here.
regards,
amit

Raise exception in function module call from SAP owned program

I need to raise an exception in a function module to terminate a transaction, display a error message and return to to previous selection screen so the user can fix the error before moving forward.......
How do you do this when the program using the function module is SAP owned?
Thank You!
Jeff

Hi,
After calling the function module, you can do something like this.
IF SY-SUBRC <> 0.
RAISE EXCEPTION.
ENDIF.
Regards,
Ferry Lianto

Raising Exception-Proxy

Hi Group,
Can any body suggest how to raise exception in ABAP proxy with custom message and I want to fail message in SXMB_MONI .
-Rajiv

Hi Rajiv
In addition to the code provided by Jorg's link above, you can also use the RAISE static method in class CL_PROXY_FAULT. This is useful if you already have error messages in the common BAPI return table.
cl_proxy_fault=>raise( exception_class_name = 'ZCL_YOUR_EXCEPTION_CLASS'
bapireturn_tab = t_bapiret2 ).
Do note that as mentioned by Jorg, you still need to define the fault message, which then causes your error to appear as an "Application Error" in the monitor. ZCL_YOUR_EXCEPTION_CLASS is subclass of CX_AI_APPLICATION_FAULT, and would be automatically generated from the fault message when you generate your proxy.
Rgds
Eng Swee

Raise exception in Start Routine

Hi,
In my start routine of the update rules, I would like to raise an exception when an entry is not found in the master data...
like this,
SELECT Y FROM TABLEX
where X = A.
IF SY-SUBRC NOT 0.
Raise Exception "Value X not maintained in TABLEX.
If you can provide me an example on how to do it, that would be great...
Thanks
Gova

Hi Gova,
you might even be able to use one of 2 standard features to solve your problem:
1.) use referential integrity check in the transfer rules
2.) use the check of existing master data (in the InfoPackage)
You find detailed description of both features in the standard documentation of the BW system.
Cheers
Andreas

Raise Exception when Executing Native SQL

Hi ALL,
             when i am executing native sql, it raises following exception:
CX_SY_NATIVE_SQL_ERROR
code as shown below:
REPORT ZABC2.
data:begin of ty_final occurs 0,
vkorg type vbrk-vkorg,
vtweg type vbrk-vtweg,
spart type vbrp-spart,
werks type vbrp-werks,
fkart type vbrk-fkart,
vbeln_invoice type vbrk-vbeln,
matnr type vbrp-matnr,
arktx type vbrp-arktx,
fkimg type vbrp-fkimg,
ntgew type vbrp-ntgew,
mwsbp type vbrp-mwsbp,
posnr type vbrp-posnr,
vbeln type likp-vbeln,
bldat type likp-bldat,
erdat type likp-erdat,
traid type likp-traid,
ernam type likp-ernam,
posnr_do type lips-posnr,
vbeln_so type vbak-vbeln,
audat_so type vbak-audat,
erdat_so type vbak-erdat,
ernam_so type vbak-ernam,
posnr_so type vbap-posnr,
vbeln_contract type vbak-vbeln,
audat_contract type vbak-audat,
erdat_contract type vbak-erdat,
ernam_contract type vbak-ernam,
vbtyp_contract type vbak-vbtyp,
posnr_contract type vbap-posnr,
end of ty_final.
TRY.
break-point.
EXEC SQL .
select
       i1.inv_vkorg,
       i1.inv_vtweg,
       i1.inv_spart,
       i1.inv_werks,
       i1.inv_fkart,
       i1.inv_vbeln,
       i1.inv_matnr,
       i1.inv_arktx,
       i1.inv_fkimg,
       i1.inv_ntgew,
       i1.inv_mwsbp
       i1.inv_posnr,
       d.do_vbeln,
       d.do_bldat,
       d.do_erdat,
       d.do_traid,
       d.do_ernam,
       d.do_posnr,
       s.so_vbeln,
       s.so_audat,
       s.so_erdat,
       s.so_ernam,
       s.so_posnr,
       c.co_vbeln,
       c.co_audat,
       c.co_erdat,
       c.co_ernam,
       c.co_vbtyp,
       c.co_posnr
into :ty_final
from (SELECT
VBAK.VBELN co_vbeln,
VBAK.AUDAT co_audat,
VBAK.ERDAT co_erdat,
VBAK.ERNAM co_ernam,
VBAK.VBTYP co_vbtyp,
VBAP.POSNR CO_POSNR
FROM VBAK , VBAP
WHERE VBAK.VBELN=vbap.vbeln
and vbak.vbtyp='G') c,
(SELECT
vbak.vbeln so_vbeln,
vbak.audat so_audat,
vbak.erdat so_erdat,
vbak.ernam so_ernam,
vbap.posnr so_posnr
FROM VBAK ,VBAP
WHERE vbak.VBELN=vbap.vbeln
and vbak.vbtyp='C') s,
(SELECT
likp.vbeln do_vbeln,
likp.bldat do_bldat,
likp.erdat do_erdat,
likp.traid do_traid,
likp.ernam do_ernam,
lips.posnr do_posnr
FROM    LIKP , LIPS
WHERE likp.VBELN=lips.vbeln
and likp.vbtyp='J'.
) d,
(SELECT
vbrk.vkorg inv_vkorg,
vbrk.vtweg inv_vtweg,
vbrp.spart inv_spart,
vbrp.werks inv_werks,
vbrk.fkart inv_fkart,
vbrk.vbeln inv_vbeln,
vbrp.matnr inv_matnr,
vbrp.arktx inv_arktx,
vbrp.fkimg inv_fkimg,
vbrp.ntgew inv_ntgew,
vbrp.mwsbp inv_mwsbp,
vbrp.posnr inv_posnr
FROM VBRK , VBRP
WHERE vbrk.VBELN=vbrp.vbeln
AND vbrk.VBTYP='M'
AND vbrk.FKART NOT IN ('S1','S2','S3')
AND vbrk.FKSTO<>'X') i1,
(SELECT
       vbelv,
       POSNV,
      vbtyp_v,
       vbeln,
       POSNN,
      vbtyp_n
FROM   VBFA
where VBTYP_V='G'
AND VBTYP_N='C'
) f1,
(SELECT
       vbelv,
       POSNV,
      vbtyp_v,
       vbeln,
       POSNN,
      vbtyp_n
FROM   VBFA
where VBTYP_V='C'
AND VBTYP_N='J'
) f2,
(SELECT
       vbelv,
       POSNV,
      vbtyp_v,
       vbeln,
       POSNN,
      vbtyp_n
FROM   VBFA
where VBTYP_V='J'
AND VBTYP_N='M'
) f3
where c.vbeln=f1.vbelv(+)
and f1.vbeln=f2.vbelv(+)
and s.vbeln=f2.vbelv(+)
and f2.vbeln=f3.vbelv(+)
and d.vbeln=f3.vbelv(+)
and i1.vbeln=f3.vbeln(+)
ENDEXEC.
**and c.vbeln=f3.vbelv(+)
**and i1.vbeln=d.vbeln(+)
*if sy-subrc <> 0.
CATCH CX_SY_NATIVE_SQL_ERROR.
ENDTRY.
*ENDIF.
break-point.

Hi,
Try using this ..
data ref1 type ref to CX_SY_NATIVE_SQL_EROR.
try.
exec sql.
endexec.
catch CX_SY_NATIVE_SQL_EROR.
write 'Error ', ref1->SQL_ERROR.
RAISE EXCEPTION myref.
endtry.
Edited by: Vasavi Kotha on Jan 6, 2009 11:26 AM

Raise exception vs bapiret2

hi,
please comment.
may i know if FM raise exception, the sy-subrc will not be zero whereas bapi bapiret2 wouldn't set sy-subrc value to non zero.
if yes, which means we use bapi bapiret2 if we still want the program to continue processing even has error?
thanks

Hi,
How ever if there is a error for particular record, it doesn't proceed processing with that record..
it starts with the next record...
But u need to know what the error or problem that's been occured..
So u need to go to the bapiret2 structure and check the messages what the problem is been...
Cheers,
Simha.
Reward all the helpful answers...

Using WWSBR_API.ADD_ITEM raises exception ITEM_CREATION_ERROR

Similar Messages

Maybe you are looking for