Ada 95 Quality and Style Guide Chapter 5

Chapter 5: Programming Practices - TOC - 5.8 USING EXCEPTIONS

5.8.2 Handlers for Others

guideline

  • When writing an exception handler for others, capture and return additional information about the exception through the Exception_Name, Exception_Message, or Exception_Information subprograms declared in the predefined package Ada.Exceptions.
  • Use others only to catch exceptions you cannot enumerate explicitly, preferably only to flag a potential abort.
  • During development, trap others, capture the exception being handled, and consider adding an explicit handler for that exception.

  • example

    The following simplified example gives the user one chance to enter an integer in the range 1 to 3. In the event of an error, it provides information back to the user. For an integer value that is outside the expected range, the function reports the name of the exception. For any other error, the function provides more complete traceback information. The amount of traceback information is implementation dependent.

    with Ada.Exceptions;
    with Ada.Text_IO;
    with Ada.Integer_Text_IO;
    function Valid_Choice return Positive is
       subtype Choice_Range is Positive range 1..3;
    
       Choice : Choice_Range;
    begin
       Ada.Text_IO.Put ("Please enter your choice: 1, 2, or 3: ");
       Ada.Integer_Text_IO.Get (Choice);
       if Choice in Choice_Range then   -- else garbage returned
          return Choice;
       end if;
       when Out_of_Bounds : Constraint_Error => 
          Ada.Text_IO.Put_Line ("Input choice not in range.");
          Ada.Text_IO.Put_Line (Ada.Exceptions.Exception_Name (Out_of_Bounds));
          Ada.Text_IO.Skip_Line;
       when The_Error : others =>
          Ada.Text_IO.Put_Line ("Unexpected error.");
          Ada.Text_IO.Put_Line (Ada.Exceptions.Exception_Information (The_Error));
          Ada.Text_IO.Skip_Line;
    end Valid_Choice;
    

    rationale

    The predefined package Ada.Exceptions allows you to log an exception, including its name and traceback information. When writing a handler for others, you should provide information about the exception to facilitate debugging. Because you can access information about an exception occurrence, you can save information suitable for later analysis in a standard way. By using exception occurrences, you can identify the particular exception and either log the details or take corrective action.

    Providing a handler for others allows you to follow the other guidelines in this section. It affords a place to catch and convert truly unexpected exceptions that were not caught by the explicit handlers. While it may be possible to provide "fire walls" against unexpected exceptions being propagated without providing handlers in every block, you can convert the unexpected exceptions as soon as they arise. The others handler cannot discriminate between different exceptions, and, as a result, any such handler must treat the exception as a disaster. Even such a disaster can still be converted into a user-defined exception at that point. Because a handler for others catches any exception not otherwise handled explicitly, one placed in the frame of a task or of the main subprogram affords the opportunity to perform final cleanup and to shut down cleanly.

    Programming a handler for others requires caution. You should name it in the handler (e.g., Error : others;) to discriminate either which exception was actually raised or precisely where it was raised. In general, the others handler cannot make any assumptions about what can be or even what needs to be "fixed."

    The use of handlers for others during development, when exception occurrences can be expected to be frequent, can hinder debugging unless you take advantage of the facilities in Ada.Exceptions. It is much more informative to the developer to see a traceback with the actual exception information as captured by the Ada.Exceptions subprograms. Writing a handler without these subprograms limits the amount of error information you may see. For example, you may only see the converted exception in a traceback that does not list the point where the original exception was raised.

    notes

    It is possible, but not recommended, to use Exception_Id to distinguish between different exceptions in an others handler. The type Exception_Id is implementation defined. Manipulating values of type Exception_Id reduces the portability of your program and makes it harder to understand.


    < Previous Page Search Contents Index Next Page >
    1 2 3 4 5 6 7 8 9 10 11
    TOC TOC TOC TOC TOC TOC TOC TOC TOC TOC TOC
    Appendix References Bibliography