Re: Error-names.

[David Marceau <davidmarceau@sympatico.ca>]

Martin Klaiber wrote:
> 
> Hi,
> 
> this is not really a programming-problem (I hope), more a question
> about english terms.
> 
> I write a library with an interface to C.  The Ada-exceptions shall
> be turned into return-values for the C-functions.  Like this:
> 
>     with Interfaces.C;
> 
>     package Something is
> 
>         -- Types:
>         type C_Integer is new Interfaces.C.int;
> 
>         -- Exceptions and errors:
>         General_Error : C_Integer := -1;
> 
>         Routine_Not_Defined : exception;
>         Routine_Not_Defined_Error : C_Integer := -2;
> 
>     and so on...
> 
>     package body Something is
> 
>         function Do_Something return C_Integer is
>         begin
>             ...
>             return 0;
>         exception
>             when Routine_Not_Defined => return Routine_Not_Defined_Error;
>             when others => return General_Error;
>         end Do_Something;
> 
>     end Something;
> 
> My problem now is that I also want to define return values for
> exceptions like Constraint_Error.  But I can't define something like:
> 
>    Constraint_Error : C_Integer := -3;
> 
> as Constraint_Error is the name for the exception.  And I don't want to
> use long names like: 'Routine_Not_Defined_Error_Constant' or similar.
> I also don't want to rename the exceptions, as other Ada-Programs might
> rely on them.
> 
> Is there an english word instead of 'error' I could use?  Like 'fault'
> for instance or 'mistake'?
> 
> Constraint_Fault, Constraint_Mistake.  Hm, sounds strange to me.  Would
> it be alright though?
> 
> Thanks a lot,
> Martin
I believe this is a case of C mentality/lifestyle being brought to Ada code.

In my opinion this is bad Ada mentality/lifestyle
The Ada idea from my understanding is to make it robust by separating all the
different kinds of errors and dealing with each appropriate based on its
context.  The C style confuses and leaves you to wonder what the hell happened
and what exactly was the root of the cause.  The other thing about it is that
because each case isn't handled separately the cleanup that one is supposed to
handle for every different exception is not handled.

SUGGESTION
-----------
don't use when others all the time.
make sure when others is used it is logged somewhere.
don't return integers in exception handlers.
it's ok to raise another more specific exception to a higher level.

The special case
----------------
If you are writing a bridge that is controlled by C executable accessing an ada
shared library then yes there may be a real reason to return constants for
errors.

Feel free to add other special cases if you want but I'm pretty sure this is the
right direction to go instead of just porting a C mentality.