TryCast schlägt fehl, wo DirectCast funktioniert (.NET 4.0)

Question

Ich finde dieses Verhalten von TryCast in .NET 4.0/VS 2010 eher verwirrend.

In meinem Verständnis funktioniert TryCast wie DirectCast, aber gibt Nothing zurück, anstatt eine Ausnahme zu werfen, wenn eine Umwandlung nicht möglich ist.

VS 2010/.NET 4

?TryCast(CType(1, Object), String) 
Nothing 
?DirectCast(CType(1, Object), String) 
"1" 

VS 2008/.NET 3,5

?TryCast(CType(1, Object), String) 
Nothing 
?DirectCast(CType(1, Object), String) 
Cannot convert to 'String'. 

.NET 3.5 Ergebnisse stehen im Einklang mit dem, was ich glaube, TryCast tut ... .NET 4 ist jedoch nicht.

Kann mir jemand bitte in die beste Richtung zeigen, um ein Objekt sicher in .NET 4 zu stringern?

Answer 1

Basierend auf Ihren Code-Beispielen beginnend mit der ? Ich schätze, Sie verwenden das unmittelbare Fenster, um Ihren Test korrekt durchzuführen? Das Problem bei diesem Ansatz besteht darin, dass das unmittelbare Fenster eine Interpretation anstelle einer tatsächlichen Bewertung ist. Dies macht es anfällig für kleine Bugs und es ist in der Tat einer von ihnen.

Wenn Sie Ihren Beispielcode nehmen und ihn zu einer einfachen VB.Net-Konsolenanwendung hinzufügen, werden Sie feststellen, dass das Verhalten von 2010 mit dem Verhalten von 2008 identisch ist (löst eine Ausnahme aus).

EDIT

Warum ist das passiert Regression? Im Jahr 2010 habe ich die VB EE Debugging Engine (Expression Evaluator) komplett umgeschrieben. Die ältere Codebasis, die ich geerbt hatte, war einfach zu kostspielig, um sie zu warten. Bis zu dem Punkt, dass das Hinzufügen neuer Funktionen zu der Engine teurer war, als dass sie von Grund auf mit einer besseren Architektur neu geschrieben wurde, die die neuen Funktionen enthielt.

Wie bereits erwähnt, Debuggen von Auswertungen ist eine Interpretation mehr als eine Ausführung von Code. Es erzwingt die Duplizierung einiger Algorithmen zwischen EE und CLR/Compiler. Einer der Bereiche, in denen Duplikate auftreten, ist die Casting-Logik. Es gibt keine Möglichkeit, den CLR-Debugger anzuweisen, ein Debug-Zeitobjekt auszugeben. Es liegt in der Verantwortung des EE, zu bestimmen, ob die Sprache, für die der Cast festgelegt wurde, tatsächlich gültig ist.

Die alte EE-Casting-Logik hatte zahlreiche Bugs (besonders im Bereich Generics und Arrays). Die neuere Infrastruktur entspricht sehr den CLR-Richtlinien. Sie werden jedoch niemals 100% Parität haben, da dies sehr nützliche Ausdrücke in der EE verbieten würde (ich könnte in Zukunft einen Blogbeitrag dazu schreiben). Aber für die meisten Fälle gilt das Verhalten.

In diesem speziellen Fall habe ich einen subtilen Fehler hinzugefügt, der einen DirectCast-Wert von Object ermöglicht, um VB Runtime Conversion-Operatoren gegen das angegebene Verhalten zu verwenden, das nur CLR-Konvertierungen zulässt. Daher ist diese Umwandlung dort erfolgreich, wo sie fehlschlagen sollte.