Exception Handling after the Catch Statement

Hi every one,
How to handle the exceptions after Catch Statement.
What does a catch statement can do?
Regards,
Johny

Hi,
Check this link:
http://help.sap.com/saphelp_nw70/helpdata/en/a9/b8eef8fe9411d4b2ee0050dadfb92b/content.htm
http://help.sap.com/saphelp_nw70/helpdata/en/cf/f2bbce142c11d3b93a0000e8353423/content.htm
Regards
Adil

Similar Messages

  • Exception handling with try/catch in acrobat

    Hi
    I have a problem using a try/catch block in my acrobat document-script. Try to enter the following into the debugger-console:
    try{nonexistentFunction();}catch(e){console.println('\nacrobat can't catch')}
    and run it. The output will be:
    nonexistentFunction is not defined
    1:Console:Exec
    acrobat can't catch
    true
    The whole point of a rty/catch block is for the application  NOT to throw an exception, but instead execute the catch-part of the  statement. However, acrobat does both: It throws an exception AND  executes the catch-block.
    Is there another way to suppress the exception, or to make the try/catch-block work as it's supposed to?

    > Also Adobe provides for free the JS or compiled file for Acrobat Reader to support the JS console.
    Where is that file located ? How to install it or where to place it ?
    What is the method referred by try67 on his site where he sells a product ?
    Is that the same as the compiled file you refer to ? or did he sell his solution to adobe ?
    It is helpful if people can get an idea of the nature of choices available and make informed decisions, than a cloak and dagger approach.
    For some jobs that we have, I have been very frustrated by a consultant who wont even give basic info for transparent billing despite all assurances for privacy, as a result we are forced to do the job ourselves.
    Dying Vet

  • Exception Handling in the OBI EE 10.1.3.4

    Hi All,
    Is it possible to implement the exception handling in the OBI EE 10.1.3.4
    For Ex: Instead of displaying the below error, is it possible to display it in the meaningful way
    [nQSError: 10058] A general error has occurred. [nQSError: 27002] Near : Syntax error [nQSError: 26012] . (HY000)
    SQL Issued: SELECT SALES_FACT.SALES_AMOUNT, TIMESTAMPDIFF(SQL_TSI_DAY, TIMESTAMP ‘1900-01-01 12:00:00’, TIMESTAMP ‘1900-01-01 12:00:00’), TIME_DIM.BUSINESS_DATE FROM SALES
    Thanks in Advance
    Siva

    Hi Deepak,
    Thank you for responding to the query that i have raised.
    As you mentioned that ORA: errors will help in diagnosing the issue.
    Do you mean that it will help in diagnosing the issue at the BMM larey & Physical layer join conditions.
    Thanks in Advance
    Siva

  • Exception Handling Standards -The exception Exception should never been thrown. Always Subclass Exception and throw the subclassed Classes.

    In the current project my exception handling implementation is as follows :
    Exception Handling Layer wise :
    DL layer :
    catch (Exception ex)
    bool rethrow = ExceptionPolicy.HandleException(ex, "Ui Policy");
    if (rethrow)
    throw;
    BL Layer
    catch (Exception ex)
    bool rethrow = ExceptionPolicy.HandleException(ex, "Ui Policy");
    if (rethrow)
    throw;
    UI Layer
    catch (Exception ex)
    bool rethrow = ExceptionPolicy.HandleException(ex, "Ui Policy");
    if (rethrow)
    Response.Redirect("ErrorPage.aspx", false);
    We have a tool to check the standards. And tool output is as follows :
    The exception Exception should never been thrown. Always Subclass Exception and throw the subclassed Classes.
    I need suggestions on how to implement the same according to standards.

    Your tool is wrong if it says to never throw Exception.  This was a common recommendation back in the .NET v1 days but has long since been thrown out.  It is perfectly fine to use Exception when you have a general exception that provides no information
    that an application can use to make an informed opinion.
    The general rules of exception throwing is to throw the most specific exception that makes sense. If there is no specific exception that applies and it would be useful for the caller to handle the exception differently than other exceptions then creating
    a custom exception type is warranted.  Otherwise throwing Exception is reasonable. As an example you might have an application that pulls back product data given an ID. There is no built in exception that says the ID is invalid. However an invalid ID
    is something that an application may want to handle differently than, say, an exception about the product being discontinued.  Therefore it might make sense to create an ItemNotFoundException exception that the application can react to.
    Conversely there is no benefit in having different exception types for disk full and disk quota met. The application will respond the same in either case.
    Michael Taylor
    http://blogs.msmvps.com/p3net

  • Comment after the commit statement.

    Hi Everyone,
    Please do have a look at this.
    Commenting on COMMIT: Example The following statement commits the current transaction and associates a comment with it:
    COMMIT COMMENT 'In-doubt transaction Code 36, Call (415) 555-2637';
    Now where can I see that comment? What is the data dictionary, which will have this detail?
    Regards,
    BS2012.

    If you look into the document for the COMMIT statement you will see this.
    COMMENT Clause
    Specify a comment to be associated with the current transaction. The 'text' is a quoted literal of up to 255 bytes that Oracle Database stores in the data dictionary view DBA_2PC_PENDING along with the transaction ID if a distributed transaction becomes in doubt. This comment can help you diagnose the failure of a distributed transaction.

  • Exception handling for all the insert statements in the proc

    CREATE PROCEDURE TEST (
    @IncrStartDate DATE
    ,@IncrEndDate DATE
    ,@SourceRowCount INT OUTPUT
    ,@TargetRowCount INT OUTPUT
    ,@ErrorNumber INT OUTPUT
    ,@ErrorMessage VARCHAR(4000) OUTPUT
    ,@InsertCase INT --INSERT CASE INPUT
    WITH
    EXEC AS CALLER AS
    BEGIN --Main Begin
    SET NOCOUNT ON
    BEGIN TRY
    DECLARE @SuccessNumber INT = 0
    ,@SuccessMessage VARCHAR(100) = 'SUCCESS'
    ,@BenchMarkLoadFlag CHAR(1)
    ,@BenchmarkFlow INT
    ,@MonthYearStart DATE
    ,@MonthYearEnd DATE
    ,@StartDate DATE
    ,@EndDate DATE
    /* Setting the default values of output parameters to 0.*/
    SET @SourceRowCount = 0
    SET @TargetRowCount = 0
    /*Setting the Start and end date for looping */
    SET @MonthYearStart = @IncrStartDate;
    SET @MonthYearEnd = @IncrEndDate;
    /* Setting the @InsertCase will ensure case wise insertion as this sp will load data in different tables
    @InsertCase =0 means data will be inserted in the target TAB1
    @InsertCase =1 means data will be inserted in the target TAB2
    @InsertCase =2 means data will be inserted in the target TAB3
    @InsertCase =3 means data will be inserted in the target TAB4
    @InsertCase =4 means data will be inserted in the target TAB5
    @InsertCase =5 means data will be inserted in the target TAB6
    if @InsertCase =0
    WHILE (@MonthYearStart <= @MonthYearEnd)
    BEGIN
    SET @StartDate = @MonthYearStart;
    SET @EndDate = @MonthYearEnd;
    /* Delete from target where date range given from input parameter*/
    DELETE FROM TAB1
    WHERE [MONTH] BETWEEN MONTH(@StartDate) AND MONTH(@EndDate)
    AND [YEAR] BETWEEN year(@StartDate) and year(@EndDate)
    /*Insert data in target-TAB1 */
    BEGIN TRANSACTION
    INSERT INTO TAB1
    A,B,C
    SELECT
    A,BC
    FROM XYZ
    COMMIT TRANSACTION
    SET @MonthYearStart = DATEADD(MONTH, 1, @MonthYearStart)
    SELECT @TargetRowCount = @TargetRowCount + @@ROWCOUNT;
    END -- End of whileloop
    END TRY
    BEGIN CATCH
    IF @@TRANCOUNT>0
    ROLLBACK TRANSACTION
    SELECT @ErrorNumber = ERROR_NUMBER() ,@ErrorMessage = ERROR_MESSAGE();
    END CATCH
    END--End of Main Begin
    I have the above proc inserting data based on parameters  where in @InsertCase  is used for case wise execution.
     I have written the whole proc with exception handling using try catch block.
    I have just added one insert statement here for 1 case  now I need to add further insert  cases
    INSERT INTO TAB4
                    A,B,C
    SELECT
                                    A,BC
    FROM XYZ
    INSERT INTO TAB3
                    A,B,C
    SELECT
                                    A,BC
    FROM XYZ
    INSERT INTO TAB2
                    A,B,C
    SELECT
                                    A,BC
    FROM XYZ
    I will be using following to insert further insert statements 
    if @InsertCase =1 
    I just needed to know where will be my next insert statement should be fitting int his code so that i cover exception handling for all the code
    Mudassar

    Hi Erland & Mudassar, I have attempted to recreate Mudassar's original problem..here is my TABLE script;
    USE [MSDNTSQL]
    GO
    /****** Object: Table [dbo].[TAB1] Script Date: 2/5/2014 7:47:48 AM ******/
    SET ANSI_NULLS ON
    GO
    SET QUOTED_IDENTIFIER ON
    GO
    CREATE TABLE [dbo].[TAB1](
    [COL1] [nvarchar](1) NULL,
    [COL2] [nvarchar](1) NULL,
    [COL3] [nvarchar](1) NULL,
    [START_MONTH] [int] NULL,
    [END_MONTH] [int] NULL,
    [START_YEAR] [int] NULL,
    [END_YEAR] [int] NULL
    ) ON [PRIMARY]
    GO
    Then here is a CREATE script for the SPROC..;
    USE [MSDNTSQL]
    GO
    /****** Object: StoredProcedure [dbo].[TryCatchTransactions1] Script Date: 2/5/2014 7:51:33 AM ******/
    SET ANSI_NULLS ON
    GO
    SET QUOTED_IDENTIFIER ON
    GO
    CREATE PROCEDURE [dbo].[TryCatchTransactions1] (
    @IncrStartDate DATE
    ,@IncrEndDate DATE
    ,@SourceRowCount INT OUTPUT
    ,@TargetRowCount INT OUTPUT
    ,@ErrorNumber INT OUTPUT
    ,@ErrorMessage VARCHAR(4000) OUTPUT
    ,@InsertCase INT --INSERT CASE INPUT
    WITH
    EXEC AS CALLER AS
    BEGIN --Main Begin
    SET NOCOUNT ON
    BEGIN TRY
    DECLARE @SuccessNumber INT = 0
    ,@SuccessMessage VARCHAR(100) = 'SUCCESS'
    ,@BenchMarkLoadFlag CHAR(1)
    ,@BenchmarkFlow INT
    ,@MonthYearStart DATE
    ,@MonthYearEnd DATE
    ,@StartDate DATE
    ,@EndDate DATE
    /* Setting the default values of output parameters to 0.*/
    SET @SourceRowCount = 0
    SET @TargetRowCount = 0
    /*Setting the Start and end date for looping */
    SET @MonthYearStart = @IncrStartDate;
    SET @MonthYearEnd = @IncrEndDate;
    /* Setting the @InsertCase will ensure case wise insertion as this sp will load data in different tables
    @InsertCase =0 means data will be inserted in the target TAB1
    @InsertCase =1 means data will be inserted in the target TAB2
    @InsertCase =2 means data will be inserted in the target TAB3
    @InsertCase =3 means data will be inserted in the target TAB4
    @InsertCase =4 means data will be inserted in the target TAB5
    @InsertCase =5 means data will be inserted in the target TAB6
    IF @InsertCase =0
    WHILE (@MonthYearStart <= @MonthYearEnd)
    BEGIN
    SET @StartDate = @MonthYearStart;
    SET @EndDate = @MonthYearEnd;
    /* Delete from target where date range given from input parameter*/
    DELETE FROM TAB1
    WHERE START_MONTH BETWEEN MONTH(@StartDate) AND MONTH(@EndDate)
    AND START_YEAR BETWEEN year(@StartDate) and YEAR(@EndDate)
    /*Insert data in target-TAB1 */
    BEGIN TRANSACTION
    INSERT INTO TAB1 (COL1,COL2,COL3)
    VALUES ('Z','X','Y')
    SELECT COL1, COL2, COL3
    FROM TAB1
    COMMIT TRANSACTION
    SET @MonthYearStart = DATEADD(MONTH, 1, @MonthYearStart)
    SELECT @TargetRowCount = @TargetRowCount + @@ROWCOUNT;
    END -- End of whileloop
    END TRY
    BEGIN CATCH
    IF @@TRANCOUNT > 0
    ROLLBACK TRANSACTION
    SELECT @ErrorNumber = ERROR_NUMBER() ,@ErrorMessage = ERROR_MESSAGE();
    END CATCH
    PRINT @SUCCESSMESSAGE
    END--End of Main Begin
    GO
    I am just trying to help --danny rosales
    UML, then code

  • 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.

  • Exception handling in Web Ui SAP CRM

    Hi Experts,
    I have a request as whenever there is some Exception in CRM UI, we get a short dump on screen. We want to avoid that and try putting something better for user to understand the issue.
    Your input is really appreciated.
    Thanks & regards,
    Rajwant Mishra

    Hi,
    In addition to what raj has said earlier...
    Its definite that you would have to put your code in try - catch block..
    there are many other exceptions those can occur depending on the action you are performing...
    there can be initial reference, there can be incorrect parameter request etc.  If you look any of the on_new_focus( it would be in context _CNxx node class) method you would find few of exceptions those should to be handled.
    After yout catch statement and before end try statement you can define an action that has to be performed. You might think of exiting the method or you can raise an error message there (refer other forums for raising messages ).
    thanks,
    BJ

  • Fundamental exception handling irritation

    Hello experts,
    I have come across a very disturbing effect when using a function module capable of asynchronous execution in a <i>try-cleanup-endtry</i> statement. Please have a look at the following simple construct:
    TRY.
        do_some_db_update( ).
        start_proc_chain_with_fm( ).
        COMMIT WORK.
      CLEANUP.
        ROLLBACK WORK.
    ENDTRY.
    The method <i>do_some_db_update( )</i> can raise an exception (when the update statement contained in it somehow fails). The method <i>start_proc_chain_with_fm( )</i> uses the fm <i>RSPC_API_CHAIN_START</i> to start some process chain, if it returns with return code <i>failed</i> we raise an exception too.
    That is, both methods potentially raise exceptions. Obviously we only want to commit the involved DB changes if neither does and we want to roll back things if one of the two raises an exception (before propagating the exception to a caller).
    Now, what happens occasionally is that the latter method fails, i.e. it actually raises an exception, however the programm flow executes both, the remaining code in the try-block (i.e. the COMMIT statement) <b>as well as</b> the CLEANUP-branch (i.e. the ROLLBACK statement, which of course has nothing to roll back by then anymore).
    Can somebody please shed some light on this, I am very confused. This behavior upsets the very basis of my understanding of how exception handling in try-catch blocks works.
    Of course I somehow suspect the function module's "asychronous" capabilities.. but actually I think this must not have an effect on the construction as such.
    Regards,
    Sebastian

    Hi Matt,
    thanks for you answer. The exception thrown is indeed my <i>chain_start_failed_ex</i> (my class-based wrapper around/equivalent of the original <i>failed</i>-"exception" returned by the function module). That is, an exception is thrown and the programm flow should definitly continue after the CLEANUP statement. However, this is not always the case.
    As for your proposal this could be a work-around for the concret problem. Nevertheless I would very much like to find a general explanation for this "mystery". In principle I think - regardless of what the methods actually do - the effect discribed should never happen..
    Regards,
    Sebastian

  • Public exception handler in database package

    I'm working on Oracle 10 g; I have a package with 10 functions, instead of writing exception for each individually is there is a way to do the same exception handler in all without repeating the exception handler in the 10 function (my exception handler is the same for the 10 function)

    It would depend on how you are using the functions, and what exactly your exception handler does.
    If, for example, your handler for no_data_found does a specific select statement, then you could put this statement in another function and call that function in the exception handler of each of the 10 functions. Note that you would need to catch the exception in eacg function, but the common code would be in one place. Something like:
    FUNCTION error_func RETURN NUMBER IS
    BEGIN
       SELECT other_stuff INTO var;
       RETURN var;
    END;
    function1 RETURN NUMBER IS;
    BEGIN
       SELECT stuff INTO var;
       RETURN var;
    EXCEPTION
       WHEN NO_DATA_FOUND
          effor_func;
    END;
    function2 RETURN NUMBER IS;
    BEGIN
       SELECT stuff INTO var;
       RETURN var;
    EXCEPTION
       WHEN NO_DATA_FOUND
          effor_func;
    END;
    function3 RETURN NUMBER IS;
    BEGIN
       SELECT stuff INTO var;
       RETURN var;
    EXCEPTION
       WHEN NO_DATA_FOUND
          effor_func;
    END;If you always run all 10 functions in sequence, then you could make a wrapper to call the functions, and catch exceptions in the wrapper. Something along the lines of:
    FUNCTION wrapper RETURN NUMBER IS;
    BEGIN
       function1;
       function2;
       function10;
    EXCEPTION
       WHEN NO_DATA_FOUND THEN
          do something;
    END;As constructed here, the wrapper wil not know which function errored nor will it continue running the other functions after getting an error.
    John

  • Regarding Exception Handling

    I have used a service call in my application and i binded the context nodes to the UI Elements, the Function module behind the Service call throws the Exceptions i used the try and catch method to get the exceptions, but i am not able to control the exceptions generated by the system . As the context is binded to elements it throwing the  exceptions because the context doesnt contain any values here (because the service call raised exception ).
    If possible to handle where i need to write the catch statements
    The following error text was processed in the system WLT : Context binding for property TEXT of "PERNR" cannot be resolved: Node VIEW.1.EMPLOYEE does not contain any elements
    The termination type was: RABAX_STATE
    The ABAP call stack was:
    Method: RAISE_FOR of program CX_WDR_ADAPTER_EXCEPTION======CP
    Method: RAISE_BINDING_EXCEPTION of program CL_WDR_VIEW_ELEMENT_ADAPTER===CP
    Method: GET_BOUND_ELEMENT of program CL_WDR_VIEW_ELEMENT_ADAPTER===CP

    I assume that you have yoru context cardinality setup as 1:n or 1:1.  If you might have a condition where the context doesn't get populated, then consider setting the context node to 0:1 or 0:n - basically not required to be populated.   Your other option would be to initialize the context yourself with an empty element - perhaps in the WDDOINIT.  Just create an empty abap structure and do the BIND_STRUCTURE on the node.  This will make things a little more difficult later if you don't have any exception, because I assume you will want to remove or overwrite this empty initial element.  If you use a BIND_TABLE later after the service call, just be sure to keep the SET_INITIAL_ELEMENTS parameter set to ABAP_TRUE.

  • Exceptions Handling Programs Needed! Pls!!!

    Hi!
       Can any one give some sample programs of how exception handling is done in abap.
      Pls send it guys looking for your reply.
      [email protected]
       Rahul.

    Hi,
    Exceptions are situations that occur while an ABAP program is being executed, in which normal continuation of the program does not make any sense.
    Exceptions can be raised either implicitly in the ABAP runtime environment or explicitly in the ABAP program.
    For example, division by zero leads to an exception in the ABAP runtime environment. It is possible to determine this situation through a query in the ABAP program and to trigger an exception there.
    See the demo program DEMO_HANDLE_EXCEPTIONS in se38.
    *-------------------------------------EXAMPLE FOR RUNTIME ERROR---------------------------------------------------------------------------
    *DATA : VALUE1 TYPE I.
    *VALUE1 = 1 / 0. "------------->>>>>> IT MAKES RUN TIME ERROR.
    *WRITE : VALUE1.
    *---------------------------------EXAMPLE FOR HOW TO CATCH THE ARITHMETIC ERROR AT THE RUN TIME USING SUBRC---------------------------------
    *DATA : VALUE1 TYPE I.
    *CATCH SYSTEM-EXCEPTIONS ARITHMETIC_ERRORS = 1.
    *VALUE1 = 1 / 0.
    *WRITE : VALUE1.
    *ENDCATCH.
    *IF SY-SUBRC = 1.
    *WRITE : ' IT MAKES ERROR'.
    *ELSE.
    *WRITE : VALUE1.
    *ENDIF.
    in abap program we handle exceptions based on value returned by the system variable SY-SUBRC.
    if SY-SUBRC = 0.
    means execution completed sucessfull.
    if SY-SUBRC = 1........n.
    means execution compleated not sucessfully.
    if sy-sbrc = 0.
    write:/ 'execution sucessfull.
    **here write logic as per u r requirement
    else sy-subrc = '1'
    message
    elseif sy-subrc eq '2'
    message
    elseif sy-subrc eq '3'
    message
    elseif sy-subrc eq '4'
    message
    endif
    messages are defined in SE91..
    these messages are 5 types..
    A Termination Message
    The message appears in a dialog box, and the program terminates. When the user has confirmed the message, control returns to the next-highest area menu.
    <b>E Error Message</b>
    Depending on the program context, an error dialog appears or the program terminates.
    <b>I (nformation)<b>
    The message appears in a dialog box. Once the user has confirmed the message, the program continues immediately after the MESSAGE statement.
    <b>S(Status Message)<b>
    The program continues normally after the MESSAGE statement, and the message is displayed in the status bar of the next screen.
    <b>W(Warning)<b>
    Depending on the program context, an error dialog appears or the program terminates.
    <b>X(Exit)<b>
    No message is displayed, and the program terminates with a short dump. Program terminations with a short dump normally only occur when a runtime error occurs. Message type X allows you to force a program termination. The short dump contains the message ID.
    regards,
    Ashokreddy.

  • 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
    29     

    its 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

  • Exception handling in  in insert statemnt

    i am inserting values in to a table in a procedure.for insert statemnt what are the possible exceptions that may occur.
    how to handle exceptions for that insert statement(other than when others)

    user639995 wrote:
    is there any possiblity to use if sql%rowcount = 0 then
    RAISE e1;
    like thisNot for an insert statement, no.
    sql%rowcount returns the number of rows effected by a DML statement.
    For any of the statements you can only check sql%rowcount after the DML statement successfully executes, and it will only return a 0 if no rows were effected by that DML statement e.g. if an update effected no rows or an insert ... select ... actually inserted no rows etc.
    If an exception occurs during a DML statement then execution will pass directly to the exception handler so you won't have the opportunity to test for sql%rowcount after the statement.
    You should have an exception handler for expected exceptions.
    If an exception is not expected then you should let your code raise it up so it is seen and not handled.
    example of defining exceptions for non-named error numbers...
    SQL> create table x (x number);
    Table created.
    SQL> insert into x values ('x');
    insert into x values ('x')
    ERROR at line 1:
    ORA-01722: invalid number
    SQL> set serverout on
    SQL> declare
      2    ex_not_number exception;
      3    pragma exception_init(ex_not_number, -1722);
      4  begin
      5    insert into x values (1);
      6    commit;
      7    insert into x values ('A');
      8    commit;
      9  exception
    10    when ex_not_number then
    11      dbms_output.put_line('An attempt to insert a value that is not a number was made.');
    12  end;
    13  /
    An attempt to insert a value that is not a number was made.
    PL/SQL procedure successfully completed.
    SQL> select * from x;
             X
             1
    SQL>Further details on exception handling here:
    [PL/SQL 101 : Exception Handling|http://forums.oracle.com/forums/thread.jspa?threadID=697262&tstart=50]

  • "catch is unreachable" compiler error with java try/catch statement

    I'm receiving a compiler error, "catch is unreachable", with the following code. I'm calling a method, SendMail(), which can throw two possible exceptions. I thought that the catch statements executed in order, and the first one that is caught will execute? Is their a change with J2SE 1.5 compiler? I don't want to use a generic Exception, because I want to handle the specific exceptions. Any suggestions how to fix? Thanks
    try {
    SendMail(....);
    } catch (MessagingException e1) {
    logger.fine(e1.toString());
    } catch (AddressException e2) {
    logger.fine(e2.toString());
    public String SendMail(....) throws AddressException,
    MessagingException {....                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

    I found the problem:
    "A catch block handles exceptions that match its exception type (parameter) and exception types that are subclasses of its exception type (parameter). Only the first catch block that handles a particular exception type will execute, so the most specific exception type should come first. You may get a catch is unreachable syntax error if your catch blocks do not follow this order."
    If I switch the order of the catch exceptions the compiler error goes away.
    thanks

Maybe you are looking for

  • Help! iPhoto and notes have become unresponsive, what can I do? Etre check results here

    this morning Notes was unresponsive when I click to share as a message, now iPhoto becomes unresponsive when I click to share. I ran etre check, and here are the results: Hardware Information:           MacBook Air (11-inch, Mid 2013)           MacBo

  • IPhoto Browser option is not showing up in import menu

    Hi, The iPhoto Browser option is not showing up in the drop down import menu in my Aperture 3.4.3.  What gives?  I want to do some targeted photo imports from my iPhoto 9.4.2. Mac Pro, Mac OS X (10.7.5), Aperture 3.4.3

  • Firefox sync not syncing data between device

    Although Firefox sync syncing, data does not advice.

  • Swap space used is above threshold of 90

    Hi all, i am facing an issues in linux box which is Swap space used is above threshold of 90 [oracle@gbaheovl21 scripts]$ free              total       used       free     shared    buffers     cached Mem:       8388608    8354400      34208         

  • ACE InDesign

    Quiero prepararme a la certificación Adobe. Al contrario del MCSE por el cual encontré libros y sitios Web gratuitos con preguntas típicas, no encuentro nada para el ACE. A 150 Euro el examen, me gustaría primero saber si tengo el nivelo. Si podéis d