Exception wird nicht ausgelöst

Beim folgendenden Code sollte eigentlich eine Exception ausgelöst werden,
allerdings bekomme ich einen übergelaufenen Wert zurück ( 2147483593 ).
Wie sorge ich dafür, dass die Function Subtraction_Int32 eine Exception auslöst (wie geplant) ?

//Hauptfunktion
internal bool Test3()
{ 
            System.Int32        intValue1                    = default(System.Int32);
            System.Int32        intValue2                    = default(System.Int32);
            System.Int32        intValue3                    = default(System.Int32);


            intValue1           = System.Int32.MinValue;
            intValue2           = 055;
            intValue3           = default(System.Int32);

            if (this.Subtraction_Int32(intValue1, intValue2, out intValue3) == false)
            {
                goto ErrorExit;
                    //--->>
                    //--->>
            }

            return true;

        ErrorExit:
            return false;
}

public bool Subtraction_Int32(System.Int32 intValue1_IN, System.Int32 intValue2_IN, out System.Int32 intValue_OUT)
{

        

            intValue_OUT = default(System.Int32);


            try
            {
                intValue_OUT = intValue1_IN - intValue2_IN;
            }
            catch (System.Exception ex)
            {
                goto ErrorExit;
                    //--->>
                    //--->>
            }

            return true;

        ErrorExit:
            return false;
}
         

checked and unchecked statements - control the overflow-checking context

>

Danke.
Ich habe jetzt bei den erweiterten Build-Einstellungen den Wert "Auf arithmetischen Über-/unterlauf überprüfen" aktiviert.
Danach wird die Exception wieder ausgelöst.
checkforoverflowunderflow

Oder Du setzt einfach das "checked" um die Berechnung, dafür ist es da.
Ich würde sowas nicht global einstellen.

Oder Du setzt einfach das "checked" um die Berechnung, dafür ist es da.
Ich würde sowas nicht global einstellen.

Die Subtrahieren-Funktion war nur die, bei welcher ich den Fehler zufällig mitbekommen habe.
In Wirklichkeit sind da noch mehr Funktionen: Addieren, Multiplizieren, Dividieren usw.
Diese möchte ich nicht alle von Hand umarbeiten müssen.

Hallo,

das wäre aber expliziter. Ansonsten solltest du zumindestens einen Kommentar dazu schreiben, da sonst nicht ersichtlich ist, warum es da überhaupt zu einer Exception kommt (denn die Standardeinstellung ist ja unchecked).

Außerdem sind Exceptions zur Logikbehandlung auch ein Anti-Pattern (und langsamer als z.B. Abfragen) sowie die Verwendung von goto ebenfalls.

PS: Warum schreibst du System.Int32 anstatt einfach nur int?
Und bei den Variablennamen (wie z.B. intValue1) solltest du nicht auch noch den Typ mit angeben (Stichwort: Ungarische Notation)!

das wäre aber expliziter. Ansonsten solltest du zumindestens einen Kommentar dazu schreiben, da sonst nicht ersichtlich ist, warum es da überhaupt zu einer Exception kommt (denn die Standardeinstellung ist ja unchecked).

Außerdem sind Exceptions zur Logikbehandlung auch ein Anti-Pattern (und langsamer als z.B. Abfragen) sowie die Verwendung von goto ebenfalls.

PS: Warum schreibst du System.Int32 anstatt einfach nur int?
Und bei den Variablennamen (wie z.B. intValue1) solltest du nicht auch noch den Typ mit angeben (Stichwort: Ungarische Notation)!

Ich habe in Visual Studio 2005 angefangen und bin es von daher so gewohnt, dass immer eine Exception kommt.
Dass keine Exception kommt und stattdessen ein falsches Ergebnis ausgegeben wird, hat mich sehr verwundert.
Desweiterer hat es mich gewundert, dass ich dies erst jetzt mitbekomme.
Ich verwende die Exceptions, damit ich den ganzen StackTrace usw. gleich so wie er ist in meine Fehlerliste eintragen kann.
Die vollqualifizerten Namen wie System.Int32 verwende ich, damit ich zwischen VB.NET und C# umschalten kann, ohne mir Gedanken zu machen.
Variablen ohne int usw. am Anfang, sind irgendwelche zusammengebastelte struct.

Ich habe in Visual Studio 2005 angefangen und bin es von daher so gewohnt, dass immer eine Exception kommt.

War in Visual Studio 2015 nicht anders. Davon abgesehen ist VS eine Entwicklungsumgebung und keine Runtime, hat also mit Exceptions-Werfen nix zutun.

Ich verwende die Exceptions, damit ich den ganzen StackTrace usw. gleich so wie er ist in meine Fehlerliste eintragen kann.

Das ist nicht die Idee von Exceptions. Und wie Th69 schon schrieb ein absoluter Anti-Pattern.

Variablen ohne int usw. am Anfang, sind irgendwelche zusammengebastelte struct.

Nein, sind sie nicht. Dann hast das offenbar nicht ganz verstanden, zumindest nicht wenn Du von den Schlüsselwörtern sprichst.

Die vollqualifizerten Namen wie System.Int32 verwende ich, damit ich zwischen VB.NET und C# umschalten kann, ohne mir Gedanken zu machen.

Das Problem Int32 ist, dass dies eine "echte" Klasse ist und kein Schlüsselwort. Daher kann man diese Klassen auch einfach überschreiben, was leider einige Projekte tun.
Es ist daher die mindeste Empfehlung, int statt Int32 zu verwenden, wenn man nicht bewusst mit über-schreibbaren Klassen arbeiten will. Auch in VB ist die Empfehlung das Schlüsselwort Integer zu nutzen, und auch hier nur Int32, wenn das notwendig ist.
Das hat was mit Code-Sicherheit zutun.

Desweiterer hat es mich gewundert, dass ich dies erst jetzt mitbekomme.

Dir ist es nicht aufgefallen, weil es in den allermeisten Fällen nicht relevant ist.
Ein Grund mehr, so eine globale Einstellung nicht zu verwenden.

Ich verwende die Exceptions, damit ich den ganzen StackTrace usw. gleich so wie er ist in meine Fehlerliste eintragen kann.

Was Th69 meint ist die Logikbehandlung.
Was Du in deinem Code machst, ist den Ablauf mit Exceptions zu steuern, der false-Fall ist ja kein Fehler, sondern ein potentiell erwartbares Verhalten, sonst könntest Du das false ja nicht behandeln.
Wenn es ein Fehler ist, dann lass die Exception fliegen und logge sie an geeigneter Stelle samt StackTrace.
Wenn es kein Fehler ist, solltest Du wann immer möglich auf Exceptions verzichten.

Die vollqualifizerten Namen wie System.Int32 verwende ich, damit ich zwischen VB.NET und C# umschalten kann, ohne mir Gedanken zu machen.

VB.NET ist tot - wurde schon vor Jahren abgekündigt.
~~Und ~~Projekte kannst Du so oder so übergreifend verwenden, am Ende kommt das gleiche Ergebnis raus.

Weil mich Abt darauf hingewiesen hat:
https://twitter.com/KathleenDollard/status/1633150673100623872
Die Sprache wird weiter unterstützt, aber (zumindest derzeit) nicht weiterentwickelt.
Damit ist die Aussage "VB.NET ist tot" natürlich falsch.
Dennoch rate ich davon ab, diese Sprache zu nutzen, das sollte man nicht als Basis für ein ganzes Projekt wählen 🙂
Und wenn man alten VB.NET-Code hat: Man kann ja projektübergreifend mischen und dann Stück für Stück umstellen.

Variablen ohne int usw. am Anfang, sind irgendwelche zusammengebastelte struct.

Eigene Namenskonventionen sind so ziemlich immer eine blöde Idee, Du fährst um Welten besser, wenn Du dich an gängige Konventionen hältst.

Und die structs:
Choosing Between Class and Struct - Framework Design Guidelines
TLDR: Wenn Du nicht weißt, was Du tust, nutze sie nicht.

Das Problem Int32 ist, dass dies eine "echte" Klasse ist und kein Schlüsselwort. Daher kann man diese Klassen auch einfach überschreiben, was leider einige Projekte tun.

Wie genau meinst Du das? Int32 ist ein struct, das nicht überschrieben werden kann O.o
Oder meinst Du Structs/Klassen mit dem gleichen Namen, oder einen using Alias?

Unglückliche / bewusst vereinfachte Formulierung.

int kannst Du nicht selbst deklarieren, weil Schlüsselwort.
Int32 kannst Du selbst deklarieren - und das machen leider einige Bibliotheken.

Wenn es ein Fehler ist, dann lass die Exception fliegen und logge sie an geeigneter Stelle samt StackTrace.

Wenn ich die Exception nicht einbaue, dann wird diese beim Absturz dem Benutzer angezeigt,
was nicht passieren soll, weil der Benutzer dann glaubt, dass das Programm nicht funktioniert.
Dass der Benutzer etwas falsch gemacht hat, auf diesen Gedanken kommt er überhaupt nicht.

Das Problem Int32 ist, dass dies eine "echte" Klasse ist und kein Schlüsselwort. Daher kann man diese Klassen auch einfach überschreiben, was leider einige Projekte tun.
Wie genau meinst Du das? Int32 ist ein struct, das nicht überschrieben werden kann O.o
Oder meinst Du Structs/Klassen mit dem gleichen Namen, oder einen using Alias?

Ich meine damit z.B.

//ganz normaler Int32-Typ
internal System.Int32 intIrgendwas = 0;

//selber zusammengebastelter struct
internal MEINE_EIGENE_STRUCT   mes = default(MEINE_EIGENE_STRUCT);

public struct MEINE_EIGENE_STRUCT
{
  public System.Int32 intMeinWert1;
  public System.Byte  bMeinWert2;
  public System.Double  dblMeinWert3;
}

Nach welchem Buch/Tutorial hast du denn gelernt?

Du kannst hier einfach folgendes benutzen:

public struct MyStructure
{
  public int meinWert1;
  public byte  meinWert2;
  public double meinWert3;
}

(statt meinWertX dann selbstverständlich anwendungsbezogene Variablen!)

Man sollte sich an die allgemeinen Codekonventionen für C# halten.

Und bei den Datentypen-Schlüsselwörtern erzeugt der Compiler dann entsprechend Code, welcher dann die zugehörigen .NET-Datentypen benutzt (es gibt [fast] keinen Grund diese direkt zu benutzen - außer evtl. für Codegeneratoren o.ä.).

Nach welchem Buch/Tutorial hast du denn gelernt?

Überhaupt keines.

Und bei den Datentypen-Schlüsselwörtern erzeugt der Compiler dann entsprechend Code, welcher dann die zugehörigen .NET-Datentypen benutzt (es gibt [fast] keinen Grund diese direkt zu benutzen - außer evtl. für Codegeneratoren o.ä.).

Das habe ich oben versucht zu erklären. Ich will überhaupt nicht erst überlegen müssen, ob ich jetzt gerade in VB.NET oder C# programmiere.
Typen wie System.Int32 funktionieren immer, sowohl in C#, wie auch in VB.NET.