• edgar (10/10) Aug 18 2004 Shouldn't an attempt to perform an invalid downcast throw an exception? ...
• teqDruid (8/18) Aug 18 2004 I believe one of the rationales is so one can do something like:
• Stewart Gordon (8/11) Aug 22 2004
• Ilya Minkov (20/32) Aug 25 2004 Current behaviour merges the downcast and a test for a downcastability.

edgar <edgaralves di.uminho.pt> writes:

Shouldn't an attempt to perform an invalid downcast throw an exception? The
current behaviour of having the cast operator return null for those cases forces
a pattern of error checking reminiscent of the C library. Or have the cases
where this could be a problem considered bad programming practices anyway?
The documentation doesn't explain the rationale behind the current behaviour,
and I was under the impression that it was considered good practice to detect
error conditions ASAP (instead of having a null pointer exception thrown later).
Since this is my first post to this newsgroup, let me just compliment you guys
on what is shaping up to be an extremely interesting language. I'm looking
forward to make some contributions myself to this effort.

teqDruid <me teqdruid.com> writes:

I believe one of the rationales is so one can do something like:
if (cast(A)b){}
To test if b is of type A.  If an exception was thrown, one would have to
catch the exception and deal with a simple if with a try catch instead. 
In addition, exceptions are (from what I've heard) slow, especially
compared to if(null).

John

On Wed, 18 Aug 2004 16:38:56 +0000, edgar wrote:

 Shouldn't an attempt to perform an invalid downcast throw an exception? The
 current behaviour of having the cast operator return null for those cases
forces
 a pattern of error checking reminiscent of the C library. Or have the cases
 where this could be a problem considered bad programming practices anyway?
 The documentation doesn't explain the rationale behind the current behaviour,
 and I was under the impression that it was considered good practice to detect
 error conditions ASAP (instead of having a null pointer exception thrown
later).
 Since this is my first post to this newsgroup, let me just compliment you guys
 on what is shaping up to be an extremely interesting language. I'm looking
 forward to make some contributions myself to this effort.

Stewart Gordon <smjg_1998 yahoo.com> writes:

edgar wrote:

 Shouldn't an attempt to perform an invalid downcast throw an exception? The
 current behaviour of having the cast operator return null for those cases
forces
 a pattern of error checking reminiscent of the C library.

<snip>

I think the idea is that the error is checked indirectly.  Because when 
you try to use the null object, it'll generate an access violation....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
on the 'group where everyone may benefit.

Ilya Minkov <minkov cs.tum.edu> writes:

Current behaviour merges the downcast and a test for a downcastability.

Say, you have a polymorphic container which collects Berries. You take 
one berry and want to determine what to do with it:
if(cast(Strawberry)berry)
	eat(berry);
else if(cast(BlackCurrant)berry)
	makeJam(berry);
else GiveSomeoneElse(berry);

Of course one could take some other way for testing the downcastability, 
but then for any of such operations this would have to be done twice.

As opposed to Java, where polymorphic containers were used for 
everything up to now and downcasting bugs are very likely and should be 
caught as early as possible, in D downcasting is only needed in special 
cases which requiere attention anyway. I don't think D's decision would 
lead to many problems in practice, though definately to some.

A possible alternative would be to make cast safe (that is throw an 
exception) and provide a downcast with current symantics in a form of 
something like a member function to classes.

-eye

edgar schrieb:
 Shouldn't an attempt to perform an invalid downcast throw an exception? The
 current behaviour of having the cast operator return null for those cases
forces
 a pattern of error checking reminiscent of the C library. Or have the cases
 where this could be a problem considered bad programming practices anyway?
 The documentation doesn't explain the rationale behind the current behaviour,
 and I was under the impression that it was considered good practice to detect
 error conditions ASAP (instead of having a null pointer exception thrown
later).
 Since this is my first post to this newsgroup, let me just compliment you guys
 on what is shaping up to be an extremely interesting language. I'm looking
 forward to make some contributions myself to this effort.