dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Aug 03, 2010 at 06:19:16PM +0100, Garth N. Wells wrote:
> On Tue, 2010-08-03 at 19:14 +0200, Anders Logg wrote:
> > On Tue, Aug 03, 2010 at 03:41:35PM +0100, Garth N. Wells wrote:
> > > On Tue, 2010-08-03 at 07:51 +0200, Florian Rathgeber wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > On 02.08.2010 18:50, Garth N. Wells wrote:
> > > > > On Mon, 2010-08-02 at 10:33 +0200, Anders Logg wrote:
> > > > >> On Sun, Aug 01, 2010 at 06:35:22PM +0100, Garth N. Wells wrote:
> > > > >>> On Sun, 2010-08-01 at 12:40 +0200, Florian Rathgeber wrote:
> > > > >>>> -----BEGIN PGP SIGNED MESSAGE-----
> > > > >>>> Hash: SHA1
> > > > >>>>
> > > > >>>> Hi,
> > > > >>>>
> > > > >>>> When using GenericTensor::down_cast() for a tentative down cast it would
> > > > >>>> be helpful if it would throw std::bad_alloc (as any dynamic_cast would
> > > > >>>> do)
> > > > >>>
> > > > >>> Do you mean std::bad_cast?
> > > > >>>
> > > > >>>> instead of invoking dolfin::error. Currently you would have to catch
> > > > >>>> std::runtime_error and check what() to distinguish a failed cast from
> > > > >>>> another dolfin::error, which is pretty inconvenient. Is there a specific
> > > > >>>> reason why it is implemented this way?
> > > > >>>>
> > > > >>>
> > > > >>> Not really.
> > > > >>>
> > > > >>> It's not too clear to me what you'd like. Would you prefer that
> > > > >>> down_cast doesn't throw an error, but leave it up to the programmer to
> > > > >>> check that a cast was successful, or just that DOLFIN catch a
> > > > >>> std::bad_cast and print more information before throwing an error?
> > > > >>
> > > > >> I think the best would be if DOLFIN caught the error, then wrote an
> > > > >> informative message (since it knows exactly what went wrong) and then
> > > > >> threw bad_cast.
> > > > >>
> > > > >
> > > > > Looks like there isn't much that can be done - std::bad_cast is only
> > > > > thrown when casting references, not pointers (as we do internally). From
> > > > > what I've read, our way of checking for a null pointer is correct.
> > > >
> > > > If down_cast() were implemented as casting the reference directly,
> > > > dynamic_cast would throw std::bad_cast if it fails.
> > > >
> > > > The check for the null pointer is correct, my point is that in this case
> > > > not a std::runtime_error should be thrown (which happens by calling
> > > > dolfin::error), but instead the message should be printed e.g. by
> > > > dolfin::warning and then a std::bad_cast thrown. That was Anders'
> > > > suggestion if I got that right.
> > > >
> > > > In that way down_cast() could be used as a tentative cast which is not
> > > > really possible if it throws the same exception that could be caused by
> > > > and DOLFIN error.
> > > >
> > >
> > > GenericTensor::down_cast now catches an exception and then throws an
> > > error. It was simpler than I thought because return statements can be
> > > used inside a try block (which I didn't know).
> > >
> > > Garth
> >
> > Does this work as intended? It still looks like we catch the exception
> > and let then throw a runtime error by calling error():
> >
> >  catch (std::exception& e)
> >  {
> >    error("GenericTensor cannot be cast to the requested type: %s", e.what());
> >  }
> >
>
> Yes. What else do we want to do other than eventually throw an error? We
> don't want to carry on with a bad cast. If a programmer wants to do
> something fancy when a cast fails, they can use dynamic_cast directly
> and catch an exception.
>
> Garth

I thought the idea was to throw a more specific exception since we
know exactly what type of exception it is. We throw away that
information when we just call error. Maybe the error() function should
take the exception as an argument so that it can throw that exception
instead of just runtime_error?

--
Anders

Attachment: signature.asc
Description: Digital signature