Re: Common exception handling

[Adam Beneschan <adam@irvine.com>]

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