Jaki jest skuteczny sposób śledzenia, identyfikowania i raportowania każdego „komunikatu o błędzie” zgłaszanego przez Twoją aplikację?

W przypadku błędów zgłaszanych przez własną aplikację, powszechnym rozwiązaniem jest posiadanie tabeli komunikatów o błędach, takich jak ta:

create table errors
    ( error_no integer primary key
    , error_text varchar2(200)
    , error_cause varchar2(4000)
    , error_action varchar2(4000)
    );

Typowym wpisem może być:

insert into errors (error_no, error_text, error_cause, error_action)
values (479, 'End date cannot be earlier than start date',
        'A start date and an end date were entered where the end date was before the start date, which is not allowed.',
        'Correct the start and end dates and retry.'
       );

Następnie w swoim kodzie obsługuj wyjątki mniej więcej tak:

if p_start_date > p_end_date then
    error_pkg.raise_error (479);
end if;

Pakiet zrobiłby coś takiego:

procedure raise_error (p_error_no integer)
is
    l_text errors.error_text%type;
begin
    select error_text into l_text
    from   errors
    where  error_no = p_error_no;
    raise_application_error(-20001, l_text);
end;

Użytkownik końcowy zobaczy coś takiego:

ERROR 479: End date cannot be earlier than start date

Można to następnie sprawdzić, aby uzyskać szczegółowe informacje o przyczynie i działaniu.

Bardziej zaawansowana wersja pozwoliłaby na wyświetlanie wartości danych w wiadomościach za pomocą symboli zastępczych w tekście błędu w następujący sposób:

insert into errors (error_no, error_text, error_cause, error_action)
values (456, 'Invalid action code: [1]',
        'An invalid action was specified', 'Correct the action code and retry.'
       );

error_pkg.raise_error (456, p_act_code);