Exception Handling Concept Gone Bad!!

Question

Okay, this is by far the most embarrassing hack of code I've done thus far . . . but it works. I am trying to run a select where if there is no data or null returned, place it into the value "v_pidm', and then let the action occur. Simple enough, right? Wrong! A select that return no data which is using a 'into' function is an exception . . . "no data found." Oracle sends this to the exception block as it should. Okay, I don't want to stop and start my script a million times, there I added an sub Begin/End with an exception to handle the say error and perform an insert. I know you shouldn't use an exception state for inserts another than capturing errors . . . you know bad practices and all. Any ideas as how to better handle the select statement that should regularly return no data? I was thinking about some along the line of nvl(v_pidm, 0) or something, but I am getting errors.
set serveroutput ON SIZE 1000000
set heading off               
set feedback off               
set trimspool off              
set echo off                   
set pagesize 0 
set termout on
Declare
error     varchar(255);
v_pidm    number(8);
Begin
    Begin   
        select distinct saraatt_pidm 
        into
        v_pidm
        from saraatt, saradap
        where saraatt_appl_no = SARADAP_APPL_NO
        and saraatt_term_code = SARADAP_TERM_CODE_ENTRY
        and saraatt_pidm = 4;
      Exception
         when too_many_rows then
        error := SQLERRM;       
        DBMS_OUTPUT.PUT_LINE(' %% Oracle Error! %% The select statement returned more than two rows ');
        when no_data_found then
        error := SQLERRM;       
        DBMS_OUTPUT.PUT_LINE('Select Returned No Data . . . Therefore Insert new record for ' || v_pidm );
        v_pidm := -999;
        when others then
        error := SQLERRM;       
        DBMS_OUTPUT.PUT_LINE(' %% Oracle Error! %% An Error Occured ' || substr(error,5,20));   
    End;
DBMS_OUTPUT.PUT_LINE('Pidm: ' || v_pidm);
End;

Answer 1

it would be better to just let the exception get propagated up so that you can see the full error stack.
Agrees fully with Justin
@Pr****
It took me a while as well, but in the end the best thing to do is avoid a WHEN OTHERS at all cost.
Once you resort to it, you're actually hiding some flaw(s), it might be design (it usually is)....or whatever, and the database covers up for t, and gets the blame.
And it's a pet-peeve of Tom Kyte for quite a while, and he wrote very good articles on it, do some readng on them:
http://google.com/search?q=site%3Atkyte.blogspot.com+%22when+others%22
Okay, I don't want to stop and start my script a million times, there I added an sub Begin/End with an exception to handle the say error and perform an insertYour example also doesn't seem to show the complete picture then?
I see no INSERT statement?
You have hidden your complete block structure, which makes it hard to guess what's going on/help you.
Perhaps you've nested your example in real life in another block, having it's own exception handler and so on...
I am getting errors.If you're getting errors and want some volunteers to help, then why not just post the full error message as well?
And your database version (the result of: select * from v$version; )