[C# / .NET] Kan SqlException niet opvangen

[Davio]

Beste Tweakers,

Ik breek mijn hoofd al anderhalve dag over het volgende stukje code:

C#:

private bool validateDb(string connString)
        {
            using (SqlConnection conn = new SqlConnection(connString))
            {
                try
                {
                    conn.Open();
                    return true;
                }
                catch
                {
                    MessageBox.Show("Test");
                    return false;
                }
            }

Excuseer de layout, copy-paste ging niet lekker.

Hij knalt er elke keer uit met een SqlException met de melding 'Logon failed', dit is niet gek want de logon klopt inderdaad niet en dat is juist de bedoeling.
Het gaat erom dat hij er keihard uitknalt en niet netjes wordt afgevangen.
Hij komt dus nooit in mijn catch, maar de debugger springt in de code met een melding.
En hij springt naar de regel die na de conn.Open() staat, in dit geval dus return true.

Als ik in mijn Project Properties het vangen van exceptions voor Unmanaged Code uitzet, dan springt hij gelijk in de Code, als ik het vangen aanzet krijg ik nog een DialogBox waar ik kan kiezen voor Break en Continue, maakt dus niet veel uit verder.

Ik probeer trouwens gewoon een verbinding te testen door met ingevoerde gegevens en een met SqlQueryBuilder opgebouwde Connection String het openen van de verbinding te proberen. Het faalt echter elke keer jammerlijk.

Ik waardeer jullie hulp op voorhand voor deze breinbreker.


Korte samenvatting: Exception wordt niet afgevangen door mijn 'catch-all', hij knalt er gewoon uit.

[beany]

En als je een release build maakt en die buiten visual studio start?

[Ventieldopje]

Moet het niet catch(Exception ex) zjin?.

[defiant]

Oeps, iets te snel op verstuur gedrukt.

Als je het volgende probeert, werkt het dan wel:

C#:

private bool validateDb(string connString)
        {
            SqlConnection conn = new SqlConnection(connString)
                try
                {
                    conn.Open();
                    return true;
                }
                catch
                {
                    MessageBox.Show("Test");
                    return false;
                }
                finally 
               {
                  conn.Dispose();
               }
}
         

[ Voor 16% gewijzigd door defiant op 04-03-2011 13:54 ]

[DonJunior]

Ventieldopje schreef op vrijdag 04 maart 2011 @ 13:48:
Moet het niet catch(Exception ex) zjin?.

Nee, dat is niet verplicht. Men kan een exception ook afvangen zonder een bericht op te vangen.

[lier]

defiant schreef op vrijdag 04 maart 2011 @ 13:52:
Als je het volgende probeert, werkt het dan wel:

Uiteraard werkt het dan wel...

Volgens mij stelt de TS vast dat bij het gebruik van using geen exceptions (door)gegooid worden. En volgens mij is dat een van de zaken (afgezien van het disposen van objecten) dat bij design zo geregeld is.

[mlowijs]

Zet je

C#:

SqlConnection conn = new SqlConnection(connString)

ook eens in de try-clausule?

[defiant]

lier schreef op vrijdag 04 maart 2011 @ 13:56:
Volgens mij stelt de TS vast dat bij het gebruiker van using geen exceptions (door)gegooid worden. En volgens mij is dat een van de zaken (afgezien van het disposen van objecten) dat bij design zo geregeld is.

Dat lijkt me ook ja.

[MindStorm]

Moet je wel binnen die try { } returnen?

[lier]

Ik zit er nog eens naar te kijken en het verbaast me eigenlijk dat het niet werkt...

Kan je als test nog de using binnen een try/catch block opnemen?
Het lijkt er namelijk op dat de Exception door de using gegooid wordt in plaats van door de .Open() methode.

MindStorm schreef op vrijdag 04 maart 2011 @ 14:03:
Moet je wel binnen die try { } returnen?

Ja.

[ Voor 23% gewijzigd door lier op 04-03-2011 14:06 ]

[lier]

Ik heb dit stukje code net geschreven...lees en huiver/verbaas je/geniet/whatever...

code:

using System;

namespace TestLibrary
{
    public class Class1
    {
        public static void Main()
        {
            try
            {
                using (ExceptionClass myClass = new ExceptionClass())
                {
                    try
                    {
                        myClass.ThrowMyException();
                    }
                    catch
                    {
                        Console.WriteLine(string.Format("Exception caught by inner block"));
                    }
                }
            }
            catch
            {
                Console.WriteLine(string.Format("Exception caught by outer block"));
            }
            finally
            {
                Console.ReadLine();
            }
        }
    }

    public class ExceptionClass: IDisposable
    {
        public ExceptionClass()
        {}

        public void ThrowMyException()
        { throw new Exception(); }

        public void Dispose()
        {}
    }
}

Het vreemde is dat je hier alleen bij de inner try/catch de exceptie tegen komt (in tegenstelling tot jouw verhaal). Zit nu even de SqlConnection.Open Method info te lezen.

[ Voor 172% gewijzigd door lier op 04-03-2011 14:15 ]

[whoami]

lier schreef op vrijdag 04 maart 2011 @ 13:56:
[...]

Uiteraard werkt het dan wel...

Volgens mij stelt de TS vast dat bij het gebruik van using geen exceptions (door)gegooid worden. En volgens mij is dat een van de zaken (afgezien van het disposen van objecten) dat bij design zo geregeld is.

Dat is BS. Using gaat geen exceptions opeten.

[Ventieldopje]

DonJunior schreef op vrijdag 04 maart 2011 @ 13:53:
[...]


Nee, dat is niet verplicht. Men kan een exception ook afvangen zonder een bericht op te vangen.

Maar wel bad practice lijkt me, je weet nu niet om wat voor exception het gaat en je kunt ook geen informatie doorgeven aan bijvoorbeeld de UI

@Davio
Weet je zeker dat de exception gegooid wordt door conn.Open() en dat het niet al mis gaat bij new SqlConnection?

[lier]

whoami schreef op vrijdag 04 maart 2011 @ 14:12:
Dat is BS. Using gaat geen exceptions opeten.

Idd...ik heb het een beetje omgedraaid.

using is het equivalent van een try/finally block, de exceptie wordt (uiteraard) gewoon naar boven door gegooid.

[Ventieldopje]

lier schreef op vrijdag 04 maart 2011 @ 14:16:
[...]

Idd...ik heb het een beetje omgedraaid.

using is het equivalent van een try/finally block, de exceptie wordt (uiteraard) gewoon naar boven door gegooid.

Het enige dat using doet is tijdelijk een resource gebruiken en die daarna automatisch disposen

[lier]

Ventieldopje schreef op vrijdag 04 maart 2011 @ 14:19:
Het enige dat using doet is tijdelijk een resource gebruiken en die daarna automatisch disposen

Idd, zie ook mijn code voorbeeld. Ik doelde meer vanuit Exception perspectief.

[whoami]

Ventieldopje schreef op vrijdag 04 maart 2011 @ 14:15:
[...]


Maar wel bad practice lijkt me, je weet nu niet om wat voor exception het gaat en je kunt ook geen informatie doorgeven aan bijvoorbeeld de UI

Dat hoeft toch niet altijd ? Als je bv de exceptie kunt afvangen, en het probleem corrigeren, dan hoef je de gebruiker niet lastig te vallen met een melding dat er iets is foutgegaan, als je het zelf in code hebt kunnen oplossen.
je kan het natuurlijk wel loggen.

[Korben]

whoami schreef op vrijdag 04 maart 2011 @ 14:38:
[...]
Dat hoeft toch niet altijd ? Als je bv de exceptie kunt afvangen, en het probleem corrigeren, dan hoef je de gebruiker niet lastig te vallen met een melding dat er iets is foutgegaan, als je het zelf in code hebt kunnen oplossen.
je kan het natuurlijk wel loggen.

Als je een catch-block hebt zonder exceptie-type, weet je uiteraard niet wat voor soort exceptie je hebt gevangen. Hoe kun je een situatie corrigeren als je niet weet wat voor soort situatie dat is? Voor hetzelfde geld is het een OutOfMemoryException. Knappe jongen die dat corrigeert

offtopic:
Ik snap natuurlijk wel dat dit niet is wat je bedoelt, maar ik wou het punt even ter educatie opvoeren.

[lier]

Korben schreef op vrijdag 04 maart 2011 @ 15:05:

offtopic:
Ik snap natuurlijk wel dat dit niet is wat je bedoelt, maar ik wou het punt even ter educatie opvoeren.

code:

catch(OutOfMemoryException)
{
  if(OS.NumberOfBits != 64) { StartInstallBetterOS();}
}

[Hooiopdevork]

Kun je ook niet SqlException opvangen

C#:

private bool validateDb(string connString) 
        { 
            using (SqlConnection conn = new SqlConnection(connString)) 
            { 
                try 
                { 
                    conn.Open(); 
                    return true; 
                } 
               Catch (SqlException sqlEx){  
                   MessageBox.Show("Test"); 
                    return false; 
               }           
 } 

[lier]

Hooiopdevork schreef op vrijdag 04 maart 2011 @ 15:20:
Kun je ook niet SqlException opvangen

SqlException is een specialisatie van Exception, dus door een catch te doen (desnoods expliciet door Exception te vangen, maar dat gebeurt impliciet al) wordt ook de SqlException afgevangen.

[Davio]

Bedankt voor alle reacties, ik had misschien al moeten melden wat ik geprobeerd had, maar ik moest even weg om een biljart te verhuizen, stond niet in mijn functieomschrijving, maar moet kunnen.

Ik heb geprobeerd om het using-block te vervangen en het aanmaken van de SqlConnection in de try-catch te gooien. Maakte geen verschil.

Ik heb geprobeerd om een specifieke Exception catch(SqlException sqlEx) op te vangen, geen resultaat. Ook heb ik het met catch(Exception ex) geprobeerd, werkte allemaal niet.

Ik weet zeker dat het fout gaat bij Open() omdat de debugger daarheen springt.

Ik heb hem van Debug op Release gezet, ook geen verschil.

Aan- en uitvinken van Enable xxx Debugging in Property settings maakte ook niks uit.


Ik snap gewoon niet waarom hij de exception niet afvangt!
Als alle settings binnen de connection string goedstaan, maakt hij trouwens verbinding zonder exception.

[lier]

Als je onderstaande probeert zou het volgens mij moeten werken (even los van of dit een gewenste oplossing is).

[code=C#]private bool validateDb(string connString)
{
try
{
using (SqlConnection conn = new SqlConnection(connString))
{
try
{
conn.Open();
return true;
}
catch
{
return false;
}
}
}
catch
{
return false;
}
}[/code=C#]

[Davio]

Helaas, geprobeerd, maar zelfde problemen.

[FireDrunk]

Op de microsoft site staat het volgende voorbeeld:

C#:

public static void ShowSqlException(string connectionString)
{
    string queryString = "EXECUTE NonExistantStoredProcedure";
    StringBuilder errorMessages = new StringBuilder();

    using (SqlConnection connection = new SqlConnection(connectionString))
    {
        SqlCommand command = new SqlCommand(queryString, connection);
        try
        {
            command.Connection.Open();
            command.ExecuteNonQuery();
        }
        catch (SqlException ex)
        {
            for (int i = 0; i < ex.Errors.Count; i++)
            {
                errorMessages.Append("Index #" + i + "\n" +
                    "Message: " + ex.Errors[i].Message + "\n" +
                    "LineNumber: " + ex.Errors[i].LineNumber + "\n" +
                    "Source: " + ex.Errors[i].Source + "\n" +
                    "Procedure: " + ex.Errors[i].Procedure + "\n");
            }
            Console.WriteLine(errorMessages.ToString());
        }
    }
}

Het zou dus gewoon moeten werken...

[Davio]

Ja, het gekke is ook dat het in een ander project wel werkt...

En ik heb voor zover ik weet niets geks in de settings van dit project staan...

Zelfde .NET target (3.5).

[FireDrunk]

ooo, wacht... Je kunt Visual Studio zo inregelen dat hij bepaalde exceptions voor jou opvangt, en bepaalde expliciet niet. Misschien moet je dat eens onderzoeken.

[masterpoi]

FireDrunk schreef op vrijdag 04 maart 2011 @ 17:21:
ooo, wacht... Je kunt Visual Studio zo inregelen dat hij bepaalde exceptions voor jou opvangt, en bepaalde expliciet niet. Misschien moet je dat eens onderzoeken.

Klopt. Om dat uit te sluiten kan je twee dingen testen:

Zonder debugger runnen: CTRL+f5 of debug> start without debugging

Exception settings resetten: Debug > Exceptions > Reset all.

[Davio]

masterpoi schreef op vrijdag 04 maart 2011 @ 17:28:
[...]


Klopt. Om dat uit te sluiten kan je twee dingen testen:

Zonder debugger runnen: CTRL+f5 of debug> start without debugging

Exception settings resetten: Debug > Exceptions > Reset all.

Het door mij dikgemaakte stuk werkte uiteindelijk. Misschien dat ik het voor een vorig project eens heb aangezet (en misschien gedacht dat dit een per project setting was) en vergeten uit te zetten.

Nu valt hij wel netjes in de catch.

Blij dat ik dit op vrijdag om half 6 nog voor elkaar heb gekregen, dank allen.