Help understanding the benefits of Ada's exception model

Help understanding the benefits of Ada's exception model

[Patrick]

Hi Everyone

I love Ada and I am so grateful for the help I have received on this list. This post is slightly negative and I really hope I will not offend those that have been so good to me....

With Ada we can define exceptions and they have an explicit place in the block structure. It appears that this form is called unchecked exceptions.

There is also checked exceptions, like in C:

if (f = fopen("someFle")) { do something ... }

Assuming that a valid test can be created, what is wrong with checked exceptions ? 

I love Ada but I have found that I don't need a large part of it as a single developer writing single threaded code.
   
Tying my code to a built in exception model means I have to choose other languages that have built in exceptions models like C++(yuck) if I want to port and that doesn't mean that there models work the same way. Checked exceptions look easy to port to virtually any language not just C.

Please help me understand the benefits of Ada's model.

Thanks for reading-Patrick

Re: Help understanding the benefits of Ada's exception model

[Patrick]

Sorry for answering my own post. I think I have not used the terms unchecked exception and check exceptions properly.  Better terms would be handling exceptions and handling error codes.

Re: Help understanding the benefits of Ada's exception model

[Dan'l Miller]

On Thursday, June 26, 2014 9:28:19 AM UTC-5, Patrick wrote:
> Sorry for answering my own post. I think I have not used the terms unchecked exception and check
> exceptions properly.  Better terms would be handling exceptions and handling error codes.

Exceptions in modern Ada (since the addition of Ada.Finalization.Controlled types in Ada1995) are extraordinarily valuable in accomplishing reclamation of resources upon unwinding the stack by invoking object O's procedure Finalize( in out  O), which allows you to release resources properly (e.g., free DRAM; increment a semaphore; close a file; abort a transaction in a database; cancel an operation in an FPGA or ASIC).  Yes, you analyze a leaf-to-root walk of every call-tree in entirely-error-code-based code, but you will get fatigued and miss at least one branch where some one or more resources should have been released upon the error, but were not.  Note that invoking Finalize is an implicit operation, without any overt source code (other than some END somewhere that was there anyway).  This is part of what C++ has since the late 1990s calls RAII:  resource allocation is initialization, or what we C++ old-timers back in the late 1980s called "all allocations in constructors; all deallocations in destructors" to achieve exception-safety.  Ada1995's Ada.Finalization.Controlled wisely brings analogues of C++ constructors and destructors to Ada.  (Btw, thank you very much for that, S. Tucker Taft & Co!)

Conversely, unlike exception safety, note that there is no cross-cutting automated assistance for error-code safety, without an extraordinary amount of temporal logic, program slicing, and term rewriting to detect as a post-mortem where the resource-to-delete's lifetime has already previously ended.  This post-mortem analysis occurs somewhat later than it does in exceptions:  the post-mortem for error codes is correlated vis a vis some (in effect entirely unrelated) integer error code conditional test on some branch not on the "happy path" of the code, whereas the analogous invocation of Finalize( in out O) occurred after the raise exception but before the handler, i.e., during the implicit unwinding of the call-stack between the instant of raising the exception and the instant of invoking the exception handler.

In general, if the error requires clean-up of resources (and especially if those resources were not allocated locally, but rather allocated hither & yon throughout the codebase), then exception-safe RAII-style deallocations triggered by raising an exception are clearly the best practice.  Conversely, if no resources need to be deallocated or if all resources were allocated locally (e.g., same function; same procedure; encapsulated in same object) or if the event was not truly an error (e.g., naturally reaching the end of file, as was eventually expected anyway), then returning integer result codes may be the best practice.  Note the change of wording there:  proper usage emphasizes result codes stating mere (non-error) outcomes, whereas exceptions emphasize errors.

Re: Help understanding the benefits of Ada's exception model

[G.B.]

On 26.06.14 16:28, Patrick wrote:
> Sorry for answering my own post. I think I have not used the terms unchecked exception and check exceptions properly.  Better terms would be handling exceptions and handling error codes.
>
Right, and the usual answer is that _if_ you want non-local
transfer of control, then checking error codes just won't do.
You'd be using something like setjmp/longjmp in C.
the alternative is to handle error codes all the way up the
call chain. The resulting code is more spaghetti-like and it
will mix both return values and special return values in
the same syntactic structure.

I can't think of a language in use today that does not have
either exception handling, or else some way to check, at compile
time, that none can occur.

Re: Help understanding the benefits of Ada's exception model

[Patrick]

Thank you Dan'l Miller  and thanks G.B

I really appreciate these answers and all of your time.

I guess as with most design decisions it boils down to "depends" and now I have much more information on what to base that decision on.

Thanks again

Re: Help understanding the benefits of Ada's exception model

[Jeffrey Carter]

On 06/26/2014 07:28 AM, Patrick wrote:
> Sorry for answering my own post. I think I have not used the terms unchecked
> exception and check exceptions properly.  Better terms would be handling
> exceptions and handling error codes.

The pitfalls of relying on error codes are well documented, the most obvious 
being the numerous cases where they're not checked. An exception cannot be ignored.

What is ideal is code that offers a check to avoid causing the exception, while 
raising the exception if the check is not used:

if not Stack.Is_Empty then
    Stack.Pop (Item => V);

    -- Use V
end if;

but

Stack.Pop (Item => V); -- raises Empty if Stack.Is_Empty

-- 
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57

Re: Help understanding the benefits of Ada's exception model

[Niklas Holsti]

On 14-06-26 18:25 , G.B. wrote:
> On 26.06.14 16:28, Patrick wrote:
>> Sorry for answering my own post. I think I have not used the terms
>> unchecked exception and check exceptions properly.  Better terms would
>> be handling exceptions and handling error codes.
>>
> Right, and the usual answer is that _if_ you want non-local
> transfer of control, then checking error codes just won't do.
> You'd be using something like setjmp/longjmp in C.
> the alternative is to handle error codes all the way up the
> call chain. The resulting code is more spaghetti-like and it
> will mix both return values and special return values in
> the same syntactic structure.
> 
> I can't think of a language in use today that does not have
> either exception handling, or else some way to check, at compile
> time, that none can occur.

Fortran?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Help understanding the benefits of Ada's exception model

[Georg Bauhaus]

On 26/06/14 18:55, Niklas Holsti wrote:
>> I can't think of a language in use today that does not have
>> either exception handling, or else some way to check, at compile
>> time, that none can occur.
>
> Fortran?

Ah, yes! Blind spot.