Re: exception parameters

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Stephen Leake wrote:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
> 
>> Wojtek Narczynski <wojtek@power.com.pl> wrote:
>> :   raise Bang( Hard, Urgent, -1);
>> 
>> Absent tasks, if I jump long with parameters, doesn't this parameter
>> passing mechanism for "exceptional gotos" create a situation where
>> program flow is just as hard to follow, or even more so because
>> the tasking protocol won't be taken into account?
> 
> Yes, it could be abused.
> 
> But there are places where it would be useful.
> 
> For example, I'm working on a database GUI. The low-level database
> interface raises Database_Error with a string parameter. I have to
> parse the string to get the actual database error code. It would be
> simpler, and actually clearer, if the error code were avaialble as a
> parameter.

A database connection type may have a primitive operation Get_Last_Error. So
when you catch Database_Error and the connection object is still here (why
should it disappear?), you can get a detailed error description from it.
Get_Last_Error could be made task unique, if connection object will be used
concurrently.

> I understand there are lots of difficult implementation issues with
> general exception parameters, and it can certainly be carried too far.
> 
> Ada allows one string parameter for exceptions. If it also allowed one
> integer parameter, that might be a nice compromise :).

But the exception is already a sort of number. Why not to allow ranges?

Connection_Lost_Error, SQL_Syntax_Error, Unknown_DB_Error : exception;
   -- A consequent set of exceptions
Database_Error renames range Connection_Lost_Error..Unknown_DB_Error;

or

subtype Database_Error is range Connection_Lost_Error..Unknown_DB_Error;
   -- A range of exceptions

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de