2010-03-16 23 views
7

J'ai une classe de base "Parent" comme ceci:Calling "Base-Getter" dans Redéfinition Getter de la propriété

using System; 
using System.Collections.Generic; 
using System.Text; 

namespace ConsoleApplication1 
{ 
    class Parent 
    { 
     private int parentVirtualInt = -1; 
     public virtual int VirtualProperty 
     { 
      get 
      { 
       return parentVirtualInt; 
      } 
      set 
      { 
       if(parentVirtualInt != value) 
       { 
        parentVirtualInt = value; 
       } 
      } 
     } 
    } 
} 

et une classe enfant comme celui-ci:

using System; 
using System.Collections.Generic; 
using System.Text; 

namespace ConsoleApplication1 
{ 
    class Child : Parent 
    { 
     public override int VirtualProperty 
     { 
      get 
      { 
       if(base.VirtualProperty > 0) 
       { 
        throw new ApplicationException("Dummy Ex"); 
       } 
       return base.VirtualProperty; 
      } 
      set 
      { 
       if(base.VirtualProperty != value) 
       { 
        base.VirtualProperty = value; 
       } 
      } 
     } 
    } 
} 

Notez que le getter dans Child appelle le getter de Parent (ou du moins c'est ce que j'ai l'intention).

J'utilise maintenant la classe "Child" en l'instanciant, en affectant une valeur (disons 4) à son objet VirtualProperty et en relisant la propriété. Lorsque j'exécute ceci, je reçois évidemment une exception ApplicationException disant "Dummy Ex". Mais si je mets un point d'arrêt sur la ligne

if(base.VirtualProperty > 0) 

de l'enfant et vérifier la valeur de base.VirtualProperty (en plaçant le curseur de la souris dessus) avant que l'exception peut être jeté (je suppose (d)), Je reçois déjà l'exception. De ceci je transmets que la déclaration base.VirtualProperty dans le "Child-Getter appelle lui-même"; genre de.

Ce que je voudrais atteindre est le même comportement que je reçois quand je change la définition de parentVirutalInt (à Parent) à protéger et utiliser base.parentVirtualInt dans le Getter de l'enfant au lieu de base.VirtualProperty. Et je ne vois pas encore pourquoi ça ne marche pas. Quelqu'un peut-il nous éclairer là-dessus? Je sens que les propriétés remplacées se comportent différemment des méthodes surchargées? Au fait: je fais quelque chose de très similaire en sous-classant une classe sur laquelle je n'ai aucun contrôle (c'est la principale raison pour laquelle ma "solution de contournement" n'est pas une option).

Amitiés

Répondre

8

Il est (sans doute) un bogue dans le débogueur. Vous pouvez ajouter votre vote à cette feedback article. Ce correctif n'est pas facile à corriger, le débogueur ne dispose pas d'un accès immédiat à l'adresse de la méthode getter de la propriété de base car l'emplacement de la table v pour le getter de propriété a été remplacé dans la classe dérivée.

Une solution de contournement possible consiste à stocker d'abord la valeur de base dans une variable locale afin que vous puissiez inspecter celle-ci. Cela ne rendra pas votre getter plus lent.