Suche Ursache einer Fehlermeldung

  • C#

Es gibt 10 Antworten in diesem Thema. Der letzte Beitrag () ist von Vainamo V.

    Suche Ursache einer Fehlermeldung

    Naja, das war jetzt nicht soo spektakulär.

    Da finde ich das schon interessanter:
    vb-paradise.de/index.php/Attac…da4e3aee30df0121cb246e751

    Edit by ~blaze~:
    *Aus anderem Thema Ausgelagert*
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „~blaze~“ ()

    @TehBasic Kann doch eigentlich nicht, denn ex.InnerException == null ? "nullChecked" : schließt doch einen Zugriff auf InnerException aus, wenn InnerException null sein sollte, oder?

    Grüße
    Väinämö

    Versuch mal nicht die Verkürzte Variante, sondern wirklich mit einem If-Statement (in Klammern). Mal schauen ob das selbe rauskommt
    In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

    @Vainamo V
    Richtig. "eigentlich"

    @Radinator
    Bei sowas:

    C#-Quellcode

    1. string Temp = ex.GetType().FullName + " :" + Environment.NewLine + .....;
    2. if (ex.InnerException == null)
    3. {
    4. Temp += "nullChecked";
    5. }
    6. else
    7. {
    8. Temp += "InnerException :" + Environment.NewLine +
    9. "Message=" + ex.InnerException.Message + ........;
    10. }

    würde es einwandfrei funktionieren und "nullChecked" angehängt werden.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    @Vainamo V
    Ja. Ist nämlich schon etwas älter. Ich hab natürlich ganz fies eine trügerische Formatierung des Codes gewählt und um das nochmal zu untermalen die roten Rechtecke eingezeichnet.
    Ein Tipp:
    Der Inhalt des Else-Teils (in der Kurzform) ist egal. Die Exception tritt trotzdem auf.

    Edit:
    Hoppla, das stimmt doch nicht. Da hab ich falsch überlegt.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Niko Ortner“ ()

    @Niko Ortner Also das ganze tritt nicht auf, wenn man alles was vor dem If steht einschließlich des + entfernt. Dann verrichtet die Abfrage ihren Dienst einwandfrei und verhindert den Zugriff auf die InnerException. Wenn man allerdings irgendetwas mit einem + davor schreibt, zerschießt es die Abfrage. Jetzt fallen mir dafür 2 mögliche Gründe ein (wobei ich eigentlich sicher bin, dass es der erste ist):
    1. Entweder die Runtime interpretiert das If erst "später" und versucht stattdessen beide Komponenten (den Text und ex.InnerException) zusammenzufügen, wobei die Exception fliegt, da InnerException ja null ist. Erstaunlich wäre dann aber, dass der Compiler das ganze ja noch korrekt interpretiert, sonst wäre ihm ja aufgefallen, dass InnerException kein String ist. (Es sei denn man hat Option Strict Off)
    2. Oder sämtliche Komponenten entwickeln bei gegebenem Szenario ein Eigenleben und machen was sie wollen. ^^
    Grüße
    Väinämö

    @Vainamo V
    Du hast es. Du glaubst es nur selbst nicht ;)
    Der ternäre Operator wertet nur den Teil aus, der auch wirklich verwendet wird. Also hier:

    VB.NET-Quellcode

    1. Dim FileContents = If(Condition, DownloadFile(A), DownloadFile(B))


    C#-Quellcode

    1. string FileContents = Condition ? DownloadFile(A) : DownloadFile(B);


    werden nicht beide Dateien heruntergeladen, sondern es wird nur die Datei heruntergeladen, die verwendet wird.
    Also daran liegt es nicht.

    Erstaunlich wäre dann aber, dass der Compiler das ganze ja noch korrekt interpretiert, sonst wäre ihm ja aufgefallen, dass InnerException kein String ist. (Es sei denn man hat Option Strict Off)

    Reingefallen :P
    Der +-Operator in C# (bzw. &-Operator in VB) verwenden hinter den Kulissen die statische Funktion String.Concat.

    VB.NET-Quellcode

    1. Public Shared Function Foo(A As String, B As Integer, C As Nullable(Of Boolean), D As DataGrid, E As IndexOutOfRangeException) As String
    2. Return A & B & C & D & E
    3. End Function


    C#-Quellcode

    1. public static string Foo(string A, int B, Nullable<bool> C, DataGrid D, IndexOutOfRangeException E)
    2. {
    3. return A + B + C + D + E;
    4. }


    Hier verwendet der Compiler einen Aufruf an die Funktion public static string Concat(params object[] args), indem einfach A bis E da reingeworfen werden: String.Concat(A, B, C, D, E). Und wie man sieht, nimmt diese ein Array von Objekten entgegen, nicht ein Array von Strings. Deshalb funktioniert das auch mit Option Strict On. (Man beachte auch, dass es in C# kein Äquivalent von Option Strict Off gibt.) Das macht z.B. Sinn, wenn man Zahlen in Strings einfügen will, ohne jedes Mal von Hand .ToString dahinter schreiben zu müssen: MessageBox.Show("Anzahl an Bananen: " & Bananas.Count)

    Wenn jetzt noch dazu kommt, dass der +-Operator eine höhere Präzedenz hat als der ==-Operator, dann hat man den Salat. Der Code oben wird nämlich in Wirklichkeit so ausgeführt:

    C#-Quellcode

    1. return (
    2. (
    3. (ex.GetType().FullName + " :" + Environment.NewLine + .......) +
    4. ex.InnerException
    5. ) == null
    6. ) ? "nullChecked" :
    7. ("InnerException :" + Environment.NewLine + .......);

    Also der String, der oben zusammengebastelt wird, wird mit ex.InnerException verknüpft. Das ergibt nie null, auch wenn ex.InnerException null ist. Deshalb wird immer der zweite String zusammengebastelt, was zur NullReferenceException führt.

    Also da kommen eine Menge kleiner Umstände zusammen, die ein großes Problem ergeben.


    @~blaze~
    Und ich wunder mich die ganze Zeit, wo die Posts plötzlich hingekommen sind.
    Übrigens war das mehr als Antwort auf @Radinator ( Was die Welt wirklich nicht braucht (Fun-Links, usw.) ) gedacht.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

Facebook
Telefonspende