Common exception handling

On Tue, 26 Aug 2008 09:49:59 -0700 (PDT), Adam Beneschan wrote:

> Maybe this use of CASE should be allowed, even if we don't go all the
> way and make exceptions first-class entities in other ways. What does
> anyone else think... would it be a worthwhile feature to propose
> adding? Or is it just too "special" (if we added this, others would
> ask, well why shouldn't we allow CASE on a string, or a record, or a
> container, or just expand it using some user-specified relational
> operator so that we can use it for everything...)?

Right, I fully agree. Ada is overloaded with "special" features.

I prefer exceptions become a "normal" discrete type (only in the interface
of). I wished to have ranges of exceptions so that one could define a group
of related exceptions, and be able to extend such groups. This could the
first step in order to make exceptions contracted.

There is a similar important case, the type tags. Tags and exceptions have
much in common. It would be very nice to find a generic mechanism for
handling such things. That would remove a lot of "magic" from the language,
IMO.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 26 Sie, 21:14, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> I wished to have ranges of exceptions

Hierarchies, not ranges.

The difference is that entities in the hierarchy can be not only
extended but also specialized and that would nicely fit in the OO part
of the language.

> This could the
> first step in order to make exceptions contracted.

Yes.

Oh, wait. We have discussed that part already and there was no
conclusion. :-)

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

On Tue, 26 Aug 2008 13:22:03 -0700 (PDT), Maciej Sobczak wrote:

> On 26 Sie, 21:14, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
>> I wished to have ranges of exceptions
>
> Hierarchies, not ranges.

Yes, but it is still a range, technically, a bounded set. The problem is
that this set can be infinite. Such structure of an ordered set have real
numbers, strings, and, of course, type hierarchies.

> The difference is that entities in the hierarchy can be not only
> extended but also specialized and that would nicely fit in the OO part
> of the language.

Extension = specialization in classic OO (and Ada). When a type is extended
by adding new members and/or methods it is a specialization of the class
rooted in the derivation base.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Maciej Sobczak schrieb:
> On 26 Sie, 21:14, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
>> I wished to have ranges of exceptions
>
> Hierarchies, not ranges.
>
> The difference is that entities in the hierarchy can be not only
> extended but also specialized and that would nicely fit in the OO part
> of the language.

Meanwhile, using a nested programming language,
we can do

type Throwable is tagged private;
...

procedure Outer is
Fail: exception;

package OO_Exception is
type Relevant_Info is new Throwable with
-- everything needed to known what
-- has happened deep down the call chain
record
...
end record;
procedure Prim_Op(Recording: Relevant_Info);

end OO_Exception;

package body OO_Exception is separate;
use OO_Exception;

procedure Inner is
begin
...
end Inner;


Scrap_Book: Relevant_Info;

begin
Inner;
exception
when Fail =>
Prim_Op(Scrap_Book);
end Outer;

--
Georg Bauhaus
Y A Time Drain http://www.9toX.de

On 26 Aug, 15:43, Adam Beneschan <a...@irvine.com> wrote:
> On Aug 26, 6:47 am, shaunpatter...@gmail.com wrote:
>
> > Yeah, it looks like the extra layer of exception handling is the only
> > way. I was hoping I could avoid that if possible.
>
> No, I don't think it's the only way. *I'm surprised no one has
> suggested this:
>
> * *exception
> * * * when E : others =>
> * * * * *Print_Test (Rec);
> * * * * *declare
> * * * * * * *use Ada.Exceptions;
> * * * * *begin
> * * * * * * *if Exception_Identity(E) = A'Identity then
> * * * * * * * * ... handling for A
> * * * * * * *elsif Exception_Identity(E) = B'Identity then
> * * * * * * * * ... handling for B
> * * * * * * *etc.
> * * * * * * *else
> * * * * * * * * ... handling for other exceptions you didn't expect,
> * * * * * * * * ... but you certainly need to aware that it could
> * * * * * * * * ... happen
> * * * * * * * * raise; *--maybe
> * * * * * * *end if;
> * * * * *end;
>
> * * * * * * * * * * * * * * -- Adam

Surely you missed a smiley off this suggestion!!! :-)

== Martin

On Aug 29, 1:32 am, Martin <martin.do...@btopenworld.com> wrote:
> On 26 Aug, 15:43, Adam Beneschan <a...@irvine.com> wrote:
>
>
>
> > On Aug 26, 6:47 am, shaunpatter...@gmail.com wrote:
>
> > > Yeah, it looks like the extra layer of exception handling is the only
> > > way. I was hoping I could avoid that if possible.
>
> > No, I don't think it's the only way. I'm surprised no one has
> > suggested this:
>
> > exception
> > when E : others =>
> > Print_Test (Rec);
> > declare
> > use Ada.Exceptions;
> > begin
> > if Exception_Identity(E) = A'Identity then
> > ... handling for A
> > elsif Exception_Identity(E) = B'Identity then
> > ... handling for B
> > etc.
> > else
> > ... handling for other exceptions you didn't expect,
> > ... but you certainly need to aware that it could
> > ... happen
> > raise; --maybe
> > end if;
> > end;
>
> > -- Adam
>
> Surely you missed a smiley off this suggestion!!! :-)

Well, I do often post silly things without smileys and assume everyone
is astute enough to figure out that I was trying to be funny. But I
wasn't being funny here. Although the above looks somewhat ugly, I
can imagine that a solution of this sort may be entirely appropriate
in some cases. Suppose, for example, that the common code isn't just
at the beginning, but is also at the end, or maybe even in the middle;
the nested exception handler/reraise solution might not be so clean in
that case. Another problem with the nested exception handler solution
is that it could incur extra overhead since exception raising isn't
necessarily cheap. That shouldn't matter in most cases, but sometimes
it might. So I don't understand why the above is so ridiculous as to
merit the comment you gave.

I would say, though, that if your exception-handling code gets that
complex, it might be time to think about declaring just one exception
and a separate data structure for passing additional exception info
around.

-- Adam

On Aug 29, 4:31*pm, Adam Beneschan <a...@irvine.com> wrote:
> On Aug 29, 1:32 am, Martin <martin.do...@btopenworld.com> wrote:
>
>
>
> > On 26 Aug, 15:43, Adam Beneschan <a...@irvine.com> wrote:
>
> > > On Aug 26, 6:47 am, shaunpatter...@gmail.com wrote:
>
> > > > Yeah, it looks like the extra layer of exception handling is the only
> > > > way. I was hoping I could avoid that if possible.
>
> > > No, I don't think it's the only way. *I'm surprised no one has
> > > suggested this:
>
> > > * *exception
> > > * * * when E : others =>
> > > * * * * *Print_Test (Rec);
> > > * * * * *declare
> > > * * * * * * *use Ada.Exceptions;
> > > * * * * *begin
> > > * * * * * * *if Exception_Identity(E) = A'Identity then
> > > * * * * * * * * ... handling for A
> > > * * * * * * *elsif Exception_Identity(E) = B'Identitythen
> > > * * * * * * * * ... handling for B
> > > * * * * * * *etc.
> > > * * * * * * *else
> > > * * * * * * * * ... handling for other exceptions youdidn't expect,
> > > * * * * * * * * ... but you certainly need to aware that it could
> > > * * * * * * * * ... happen
> > > * * * * * * * * raise; *--maybe
> > > * * * * * * *end if;
> > > * * * * *end;
>
> > > * * * * * * * * * * * * * * -- Adam
>
> > Surely you missed a smiley off this suggestion!!! :-)
>
> Well, I do often post silly things without smileys and assume everyone
> is astute enough to figure out that I was trying to be funny. *But I
> wasn't being funny here. *Although the above looks somewhat ugly, I
> can imagine that a solution of this sort may be entirely appropriate
> in some cases. Suppose, for example, that the common code isn't just
> at the beginning, but is also at the end, or maybe even in the middle;
> the nested exception handler/reraise solution might not be so clean in
> that case. *Another problem with the nested exception handler solution
> is that it could incur extra overhead since exception raising isn't
> necessarily cheap. *That shouldn't matter in most cases, but sometimes
> it might. *So I don't understand why the above is so ridiculous as to
> merit the comment you gave.
>
> I would say, though, that if your exception-handling code gets that
> complex, it might be time to think about declaring just one exception
> and a separate data structure for passing additional exception info
> around.
>
> * * * * * * * * * * * * * * * * *-- Adam

Sorry - back again!

It was mostly the (to my eyes) sheer "ugliness" of the
if..elsif..elsif..end if;.

I find these sorts of structures very hard to follow (was there a
sneeky 'and then <boolean_expression>' snuck into one of the
branches???

-- Martin

On Sep 10, 3:51 pm, Martin <martin.do...@btopenworld.com> wrote:
> On Aug 29, 4:31 pm, Adam Beneschan <a...@irvine.com> wrote:
>
>
>
> > On Aug 29, 1:32 am, Martin <martin.do...@btopenworld.com> wrote:
>
> > > On 26 Aug, 15:43, Adam Beneschan <a...@irvine.com> wrote:
>
> > > > On Aug 26, 6:47 am, shaunpatter...@gmail.com wrote:
>
> > > > > Yeah, it looks like the extra layer of exception handling is the only
> > > > > way. I was hoping I could avoid that if possible.
>
> > > > No, I don't think it's the only way. I'm surprised no one has
> > > > suggested this:
>
> > > > exception
> > > > when E : others =>
> > > > Print_Test (Rec);
> > > > declare
> > > > use Ada.Exceptions;
> > > > begin
> > > > if Exception_Identity(E) = A'Identity then
> > > > ... handling for A
> > > > elsif Exception_Identity(E) = B'Identity then
> > > > ... handling for B
> > > > etc.
> > > > else
> > > > ... handling for other exceptions you didn't expect,
> > > > ... but you certainly need to aware that it could
> > > > ... happen
> > > > raise; --maybe
> > > > end if;
> > > > end;
>
> > > > -- Adam
>
> > > Surely you missed a smiley off this suggestion!!! :-)
>
> > Well, I do often post silly things without smileys and assume everyone
> > is astute enough to figure out that I was trying to be funny. But I
> > wasn't being funny here. Although the above looks somewhat ugly, I
> > can imagine that a solution of this sort may be entirely appropriate
> > in some cases. Suppose, for example, that the common code isn't just
> > at the beginning, but is also at the end, or maybe even in the middle;
> > the nested exception handler/reraise solution might not be so clean in
> > that case. Another problem with the nested exception handler solution
> > is that it could incur extra overhead since exception raising isn't
> > necessarily cheap. That shouldn't matter in most cases, but sometimes
> > it might. So I don't understand why the above is so ridiculous as to
> > merit the comment you gave.
>
> > I would say, though, that if your exception-handling code gets that
> > complex, it might be time to think about declaring just one exception
> > and a separate data structure for passing additional exception info
> > around.
>
> > -- Adam
>
> Sorry - back again!
>
> It was mostly the (to my eyes) sheer "ugliness" of the
> if..elsif..elsif..end if;.
>
> I find these sorts of structures very hard to follow (was there a
> sneeky 'and then <boolean_expression>' snuck into one of the
> branches???

That sort of argues for an extended "case" statement that is just
syntactic sugar for a series of equality comparisons. (Dmitry alluded
to that up above.) Without changing the language, I suppose you could
turn each "case" branch into a procedure and set up a search table
that maps Exception_ID's into procedure accesses. Maybe that would be
a little less ugly. Both of these ideas would be essentially
equivalent to the if/elsif/elsif... but perhaps more aesthetic.

However, I do *not* think it's necessarily a good idea to change the
structure around just for aesthetic reasons. Using nested exception
handlers may look nicer, but to me this is a fundamentally different
control structure---which, as I mentioned, may break down if you also
have common code that needs to be performed *after* the specific code
for each exception. I'd rather write something that looks a bit ugly
than twist the code around to make it fit into a control structure
that doesn't do as good job of reflecting how I see the problem at
hand.

-- Adam