Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > [Design] Should accessors throw exception ?

Reply
Thread Tools

[Design] Should accessors throw exception ?

 
 
Gennaro Prota
Guest
Posts: n/a
 
      09-14-2008
James Kanze wrote:
> On Sep 13, 6:28 pm, Gennaro Prota <gennaro/(E-Mail Removed)> wrote:
>> James Kanze wrote:
>>> Which is why I choose to return a pointer if I need a sentinal
>>> value. (In cases where I don't actually have something to
>>> point to, for example if the function returns a calculated
>>> value, I will use Fallible.)

>
>> Do you have particular reasons to avoid Fallible references?

>
> Well, the original implementation of Fallible required that the
> instantiation type be default constructable, so you couldn't
> instantiate it with a reference. At the time, I considered
> removing this limit, precisely in order to support references.
> I decided against it on the grounds that the standard already
> defined a Fallible for references---it's called a pointer.


Yes, that answers my question. Compared to a pointer, of course,
Fallible<> also provides a check (which may be or not what you want, but
is a feature ).

FWIW, my implementation of Fallible allows references, because it holds
the T indirectly, via a holder< T > which is specialized for reference
types, but I haven't had so far a concrete chance to use them. This was
part of the reason for my question.

> I recently did modify my Fallible to support types without
> default constructors. But that was because I needed it for an
> actual class type which didn't have a default constructor. The
> alternative would have been to add a default constructor to the
> class, which would have required adding a zombie state to the
> class. And which, of course, would have only solved the problem
> in this one particular case, and not generally.


Yes, that certainly makes sense. I've encountered the same issue and,
for the moment, I just did without Fallible, as I'm right in the middle
of other interesting stuff

--
Gennaro Prota | name.surname yahoo.com
Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      09-15-2008
On Sep 14, 8:07 pm, Gennaro Prota <gennaro/(E-Mail Removed)> wrote:
> James Kanze wrote:
> > On Sep 13, 6:28 pm, Gennaro Prota <gennaro/(E-Mail Removed)> wrote:
> >> James Kanze wrote:
> >>> Which is why I choose to return a pointer if I need a sentinal
> >>> value. (In cases where I don't actually have something to
> >>> point to, for example if the function returns a calculated
> >>> value, I will use Fallible.)


> >> Do you have particular reasons to avoid Fallible references?


> > Well, the original implementation of Fallible required that the
> > instantiation type be default constructable, so you couldn't
> > instantiate it with a reference. At the time, I considered
> > removing this limit, precisely in order to support references.
> > I decided against it on the grounds that the standard already
> > defined a Fallible for references---it's called a pointer.


> Yes, that answers my question. Compared to a pointer, of
> course, Fallible<> also provides a check (which may be or not
> what you want, but is a feature ).


It provides an earlier check, but on all of the implementations
I use, dereferencing a null pointer causes a core dump, exactly
like using the value of Fallible<> when it's not valid. (Well,
almost exactly: the check for accessing through a null pointer
has no runtime cost, and cannot be disabled; the check for using
an invalid Fallible<> is an assertion.)

> FWIW, my implementation of Fallible allows references, because
> it holds the T indirectly, via a holder< T > which is
> specialized for reference types, but I haven't had so far a
> concrete chance to use them. This was part of the reason for
> my question.


Well, I'd still use a pointer rather than a Fallible reference,
simply because it is standard. On the other hand, as I said, I
did need a Fallible once for a class which didn't have a
reasonable default constructor. I don't have any Holder<>
class; I just implemented the usual separation of allocation and
initialization directly in Fallible<> (using an unsigned char[]
in the Fallible<> for allocation).

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
To throw or to throw not? Emanuele D'Arrigo Python 6 11-15-2008 04:12 PM
sendmail should throw an exception but does not Clodoaldo Python 4 03-25-2008 03:04 PM
Should an overloaded, non-member operator throw? Ralph Moritz C++ 1 12-21-2006 05:29 AM
JNI's throw new does not throw an exception yarona@m-sys.com Java 15 09-08-2005 08:36 AM
Throw Exception Vs Throw New Exception Kerri ASP .Net 2 10-27-2003 02:13 PM



Advertisments