[java] SQLException probs

[simon]

Beste luitjes,

Ik ben sinds een paar dagen bezig met java, en ben nu begonnen met MySQL connecties.
Nu loop ik vast op dit stuk code. Hij throwt hier dus een exception (SQLException) en die 'heet' e. Dit gebeurt met het hieronderstaande stuk code:

Java:

    protected Connection getConnection( String host, String database, String username, String password )
    throws SQLException {
        String url = "";
        try {
            
            url = "jdbc:mysql://" + username + ":" + password + "@" + host + "/" + database;
            Connection con = DriverManager.getConnection(url);
            this.out.println("Connection established to " + url + "...");
     
            return con;
        } catch ( SQLException e ) {
            this.out.println("Connection couldn't be established to " + url);
            throw ( e );
        }
    }

Nu levert dat de volgende error op tijdens het builden:
unreported exception java.sql.SQLException; must be caught or declared to be thrown

Ik kan de hele catch zwikzwak niet wegmieten, getconnection heeft 't nodig, verder kan ik totaal geen fouten zien, java.sql.* wordt geimporteerd.

Weet iemand hoe ik dit kan oplossen?

[Alarmnummer]

Jij werpt een SQLException op die je dus niet afhandeld. En ik zie in jouw code dat jij ook een exception catch, maar deze vervolgens weer fijn omhoog gooit.

[simon]

Alarmnummer schreef op zondag 06 februari 2005 @ 10:52:
Jij werpt een SQLException op die je dus niet afhandeld. En ik zie in jouw code dat jij ook een exception catch, maar deze vervolgens weer fijn omhoog gooit.

ja, ik heb 't ook maar van een code voorbeeld, maar naar mijn analyse (van een java noob) kan ik die throw ook niet weghalen, stel dat het misgaat (dat vang je af) gooi je een 'error/uitzondering'.. Klopt dat?

[zneek]

Simon schreef op zondag 06 februari 2005 @ 10:53:
[...]

ja, ik heb 't ook maar van een code voorbeeld, maar naar mijn analyse (van een java noob) kan ik die throw ook niet weghalen, stel dat het misgaat (dat vang je af) gooi je een 'error/uitzondering'.. Klopt dat?

Dat klopt. Maar als jij hem gooit vanuit deze methode moet je hem in de aanroepende methode vangen, en er iets mee doen. Of weer doorgooien, hoger en hoger, tot een punt dat je er iets mee kan doen, bijvoorbeeld besluiten dat de applicatie gestopt moet worden.

Als je nu die throw eens weghaalt, en vervangt door een System.out.println("" +e); Dan loopt je app door in het geval van een exceptie, maar dan zie je in de console wat er fout gegaan is. Gebruik dit alleen om te testen, in een echte applicatie wil je niet dat dit soort fouten op dit lage niveau onopgemerkt blijft. Dan wil je de exceptie in je aanroepende methode binnenkrijgen, en daar bijvoorbeeld een foutmelding tonen aan de gebruiker.

[ Voor 16% gewijzigd door zneek op 06-02-2005 11:08 ]

[Alarmnummer]

Simon schreef op zondag 06 februari 2005 @ 10:53:
[...]

ja, ik heb 't ook maar van een code voorbeeld, maar naar mijn analyse (van een java noob) kan ik die throw ook niet weghalen, stel dat het misgaat (dat vang je af) gooi je een 'error/uitzondering'.. Klopt dat?

Het ligt eraan. Als jij nu een oplossing voor het probleem kunt geven.

voorbeeld in mijn eigen systeem:
ik wil informatie over een boek ophalen van amazon. Ik heb een contract (een interface) waarin een methode staat met de volgende omschrijving: haalt info van amazon op basis van een isbn.. als er een fout optreed, of het boek niet wordt gevonden, dan null terug sturen.. Anders alle informatie over dat boek.

In dit contract definieer ik dus dat de methode null terug mag sturen als er een fout optreed. Ik kan dus de fout afvangen en null terug sturen. Het systeem eronder kan zijn werk met en zonder foute communicatie naar amazon goed doen (krijgt toch null terug).

In andere gevallen kan het vervelender zijn. Stel je hebt een bank applicatie, en ergens onder in een systeem doet zich een fout voor, dan moet deze fout doorborrelen naar boven. In tegenstelling tot de meeste andere programmeurs moet je een exception van een lager nivo wel gaan afvangen en transformeren naar een exception van een hoger abstractie nivo. Mensen (vooral c++ en c# dudes) die zeggen dat je een exception pas moet afvangen als je weet wat je er mee moet doen... doen het allemaal fout.. Maarja.. krijg je ook met een taal zonder checked exceptions (ff flamen)

[simon]

zneek schreef op zondag 06 februari 2005 @ 11:06:
[...]


Dat klopt. Maar als jij hem gooit vanuit deze methode moet je hem in de aanroepende methode vangen, en er iets mee doen. Of weer doorgooien, hoger en hoger, tot een punt dat je er iets mee kan doen, bijvoorbeeld besluiten dat de applicatie gestopt moet worden.

Als je nu die throw eens weghaalt, en vervangt door een System.out.println("" +e); Dan loopt je app door in het geval van een exceptie, maar dan zie je in de console wat er fout gegaan is.

Met

Java:

    protected Connection getConnection( String host, String database, String username, String password )
    throws SQLException {
        String url = "";
        try {
            
            url = "jdbc:mysql://" + username + ":" + password + "@" + host + "/" + database;
            Connection con = DriverManager.getConnection(url);
            this.out.println("Connection established to " + url + "...");
            
            return con;
        } catch ( SQLException e ) {
            this.out.println("Connection couldn't be established to " + e);
            //throw ( e );
        }
    }

Krijg ik de volgende errors:
missing return statement }
must be caught or declared to be thrown getConnection( "localhost", "**", "***", "****");

[Alarmnummer]

Ik zou gewoon die exception niet afvangen, want die create connection zit op hetzelfde abstractie nivo als de plek waar je het gebruikt. Dus afblijven...

Jij zult in de code waar je gebruik maakt van die connection moeten werken met een try catch of je zult de exception moeten doorgeven (eventueel transformeren)

[Gert]

Als er nu een exceptie is dan wordt die opgevangen, afgehandeld en gaat ie verder na het } maar daar staat niets. Dus een return null zou kunnen, of je declareerd Connection conn = null boven de try/catch en doet onderaan return conn. Als het goed gaat is conn een connectie en anders is ie null.

[simon]

Alarmnummer schreef op zondag 06 februari 2005 @ 11:15:
Ik zou gewoon die exception niet afvangen, want die create connection zit op hetzelfde abstractie nivo als de plek waar je het gebruikt. Dus afblijven...

Jij zult in de code waar je gebruik maakt van die connection moeten werken met een try catch of je zult de exception moeten doorgeven (eventueel transformeren)

Als ik de exception niet afvang, dus geen throw/catch gedoe dan zegt de compiler dat dat ontbreekt, waarschijnlijk moet die erin..


Dit daarentegen:

Java:

    protected Connection getConnection( String host, String database, String username, String password )
     {
        String url = "";
        try {
            
            url = "jdbc:mysql://" + username + ":" + password + "@" + host + "/" + database;
            Connection con = DriverManager.getConnection(url);
            this.out.println("Connection established to " + url + "...");
            
            return con;
        } catch ( SQLException e ) {
            this.out.println("Connection couldn't be established to " + e);
            return null;
        }
    }

Werkt wel.. maar nu weet ik niet of dit netjes is..

[Alarmnummer]

Je zult dan de exception moeten propageren..

dus

Connection makeConnection()throws SQLException{...jouw code }

En die null terug sturen is een slechte oplossing want je raakt informatie kwijt.

[ Voor 27% gewijzigd door Alarmnummer op 06-02-2005 11:33 ]

[zneek]

Alarmnummer schreef op zondag 06 februari 2005 @ 11:09:
[...]

Mensen (vooral c++ en c# dudes) die zeggen dat je een exception pas moet afvangen als je weet wat je er mee moet doen... doen het allemaal fout.. Maarja.. krijg je ook met een taal zonder checked exceptions (ff flamen)

Dat zei ik ook net Maar ik bedoelde dat hij voor het testen maar eens moet gaan spelen met wel of niet catchen en throwen.

Misschien ook nog een handig voorbeeldje: ik werk met een DAO class, deze regelt alle find, save en update functionaliteit voor een bepaalde entity. Als ik bijv findAll() aanroep kan er van alles misgaan: de onderliggende database kan onbereikbaar zijn, de betreffende tabel kan missen in de database, de communicatie met de database server kan halverwege fout gaan. Allemaal exceptions op een lager niveau die allemaal in de DAO gevangen worden, en als 1 exception omhoog gegooid worden: DAOException. 1 niveau hoger heb ik niets aan de info dat de db onbereikbaar was, ik kan daar alleen wat met het feit dat mijn findAll opdracht mislukt is. Op basis daarvan besluit ik om de functie te stoppen, en de gebruiker een foutscherm te tonen.

[simon]

Alarmnummer schreef op zondag 06 februari 2005 @ 11:32:
Je zult dan de exception moeten propageren..

dus

Connection makeConnection()throws SQLException{...jouw code }

En die null terug sturen is een slechte oplossing want je raakt informatie kwijt.

Die makeConnection is bij mij getConnection? En als ik dat doe krijg ik dus die error dat SQLException niet defined oid is...

[Alarmnummer]

Simon schreef op zondag 06 februari 2005 @ 11:46:
[...]

Die makeConnection is bij mij getConnection? En als ik dat doe krijg ik dus die error dat SQLException niet defined oid is...

Als die not defined is dan heb je a) het niet goed geschreven b) niet geimporteerd...

[zneek]

Alarmnummer schreef op zondag 06 februari 2005 @ 11:32:
Je zult dan de exception moeten propageren..

dus

Connection makeConnection()throws SQLException{...jouw code }

En die null terug sturen is een slechte oplossing want je raakt informatie kwijt.

Die null terug sturen kan natuurlijk wel, maar de vraag is wat de aanroepende code er mee doet. Zoals je zelf al zei, als je in het contract definieert dat getConnection null terug geeft in het geval van een probleem, dan is het prima. Ik zou zelf niet overal willen controleren of ik wel echt een connection terug gekregen heb. Wat dat betreft heeft Alarmnummer helemaal gelijk als hij zegt dat het niet verstandig is om null terug te geven. getConnection is nogal bepalend voor de werking van je app, en een SQLException zal hoe dan ook doorgegooid moeten worden zodat je je app in een foutstaat kunt brengen.

[simon]

Alarmnummer schreef op zondag 06 februari 2005 @ 11:49:
[...]


Als die not defined is dan heb je a) het niet goed geschreven b) niet geimporteerd...

Ik kan hier geen tikfout in vinden: http://www.jackabuzah.com/emp/simon/error2.txt

[zneek]

Simon schreef op zondag 06 februari 2005 @ 11:56:
[...]

Ik kan hier geen tikfout in vinden: http://www.jackabuzah.com/emp/simon/error2.txt

Je throwed hem niet. Maar dan nog zou ie geen fout moeten geven. Wat is de precieze compile fout?

[simon]

zneek schreef op zondag 06 februari 2005 @ 12:01:
[...]


Je throwed hem niet. Maar dan nog zou ie geen fout moeten geven. Wat is de precieze compile fout?

Als ik 'm throw krijg ik de volgende error:

init:
deps-jar:
Compiling 1 source file to C:\Documents and Settings\Simon de la Court\Java\TestApp\build\web\WEB-INF\classes
C:\Documents and Settings\Simon de la Court\Java\TestApp\src\TestServlet.java:45: ';' expected
throw SQLException
1 error
C:\Documents and Settings\Simon de la Court\Java\TestApp\nbproject\build-impl.xml:184: The following error occurred while executing this line:
C:\Documents and Settings\Simon de la Court\Java\TestApp\nbproject\build-impl.xml:92: Compile failed; see the compiler error output for details.
BUILD FAILED (total time: 0 seconds)

Functie:

protected Connection getConnection( String host, String database, String username, String password )
throw SQLException

[ Voor 9% gewijzigd door simon op 06-02-2005 12:17 ]

[Alarmnummer]

Lees die foutmelding nou eens heel goed.... *moppelt iets over ;*

[simon]

Alarmnummer schreef op zondag 06 februari 2005 @ 12:26:
Lees die foutmelding nou eens heel goed.... *moppelt iets over ;*

Mijn fout, miste een S

Java:

    protected Connection getConnection( String host, String database, String username, String password )
    throws SQLException
    {
        String url = "";
        try {
            
            url = "jdbc:mysql://" + host + "/" + database;
            Connection con = DriverManager.getConnection(url, username, password);
            this.out.println("Connection established to " + url + "...");
            
            return con;
        } catch ( SQLException e ) {
            this.out.println("Connection couldn't be established to " + e);
            throw ( e );
            //return null;
            
        }
    }

Levert de volgende error op:

unreported exception java.sql.SQLException; must be caught or declared to be thrown

[ Voor 6% gewijzigd door simon op 06-02-2005 12:59 ]

[simon]

Vreemd, het lijkt of die hele SQLException niet bestaat, als ik while ( rs.next() ) { gebruik waar rs een ResultSet is zeurt hij ook om SQLException:
unreported exception java.sql.SQLException; must be caught or declared to be thrown
En als ik zeg dat die functie die kan throwen krijg ik daar een compile error op

Zou het aan een brakke jconnect liggen?

[misfire]

Lees de Sun Java Tutorial maar eens door, want zo schiet het niet op. Daar staan dingen in een logische volgorde uitgelegd. Je moet namelijk eerst weten wat exceptions zijn en hoe je hiermee in Java om moet gaan voordat je fatsoenlijk dingen als JDBC kunt gebruiken...

[zneek]

misfire schreef op zondag 06 februari 2005 @ 14:16:
Lees de Sun Java Tutorial maar eens door, want zo schiet het niet op. Daar staan dingen in een logische volgorde uitgelegd. Je moet namelijk eerst weten wat exceptions zijn en hoe je hiermee in Java om moet gaan voordat je fatsoenlijk dingen als JDBC kunt gebruiken...

Inderdaad.

Trouwens, een goede IDE is ook aan te raden. Ik gebruik bijvoorbeeld Eclipse www.eclipse.org en die geeft me al netjes aan welke exceptions er gegooid worden.

[simon]

Sorry dat ik jullie weer zo lastig val, maar zelfs na die manual/tutorial kom ik er echt niet.

Ik heb dit stukje code:

Java:

    protected void test()
    throws SQLException
    {
        ResultSet rs = this.query("SELECT id,username FROM `f30_users`");
        while ( rs.next( ) ) {
            String id = ( rs.getObject("id").toString() );
            String text = ( rs.getObject("username").toString() );
            
            this.out.println( "found record : " + id + " " + text );
        }
    }

Daar lijkt mij niets mis mee. Als ik het niet aanroep compilet hij perfect. Maar zodra ik het aanroep gaat het mis en krijg ik de volgende error:

C:\Documents and Settings\Simon de la Court\GuestBook\src\java\View.java:70: unreported exception java.sql.SQLException; must be caught or declared to be thrown

Op die ene regel staat de 'aanroep'... Zolang ik niets met die SQLException doe (dus geen functie aanroep die die exception gebruikt) kan ik laten throwen, maar op het moment dat er dus een SQL functie bijkomt geeft hij meteen een compile error met must be caught or declared to be thrown erin... Nu kom ik er op geen enkele mogelijke manier met die SJ tutorial uit, en over IDE's, ik werk met NetBeans 4

[Gert]

Als je een functie aanroept die een exceptie kan gooien dan moet je die of opvangen of door gooien. Dus in je View.java doe je iets met die methode, zet daar een try/catch om heen en om het mooi te maken kan je dan de gebruiker laten weten als de fout optreedt.

[simon]

Gert schreef op zondag 06 februari 2005 @ 18:39:
Als je een functie aanroept die een exceptie kan gooien dan moet je die of opvangen of door gooien. Dus in je View.java doe je iets met die methode, zet daar een try/catch om heen en om het mooi te maken kan je dan de gebruiker laten weten als de fout optreedt.

Jep, heb 't nu begrepen, naja, ik bouw zo ongeveer voor elke functie nu een 'verwerker' aan die catcht, en keurig errors geeft.. Kost wat maar werkt goed. Iig werkt het voor nu.. Bedankt voor de uitleg, Gert en de anderen

[Daos]

Wat ik standaard doe is zoiets:

Java:

try {
  //code
}
catch (Exception e){
  throw(new RuntimeException(e));
}

In methoden die dit stukje hebben aangeroepen hoeft geen try en catch meer te staan.

[zneek]

Simon schreef op zondag 06 februari 2005 @ 19:33:
[...]

Jep, heb 't nu begrepen, naja, ik bouw zo ongeveer voor elke functie nu een 'verwerker' aan die catcht, en keurig errors geeft.. Kost wat maar werkt goed. Iig werkt het voor nu.. Bedankt voor de uitleg, Gert en de anderen

Dat lijkt me ook geen goede oplossing. Misschien moet je je toch iets meer verdiepen in OO design. Je kiest voor een aparte verwerker class als die ook een echte eigen taak heeft. Als die alleen als bedoeling heeft om excepties af te vangen .... tjah, niet echt mooi.

Wat probeer je precies te doen? Wat doet je applicatie?

[zneek]

Daos schreef op zondag 06 februari 2005 @ 19:58:
Wat ik standaard doe is zoiets:

Java:

try {
  //code
}
catch (Exception e){
  throw(new RuntimeException(e));
}

In methoden die dit stukje hebben aangeroepen hoeft geen try en catch meer te staan.

Tjah, als je er compile time maar geen last van hebt

Wat je hiermee doet is bij elke Exception je hele applicatie stop gooien. Soms treden exceptions op, maar hoeft je applicatie niet plat te gaan, toch? Of in ieder geval moet de fout netjes afgehandeld worden. Je toont de gebruiker toch niet bij elk stukje foutief ingevoerd data een Tomcat http 500 scherm, of wel? Gewoon een try catch in je doPost of doGet die in de catch de response redirect naar een fout pagina oid.

[simon]

Ok, ik heb een Servlet waarmee ik bijvoorbeeld een gastenboek heb, en nu haal ik gegevens uit m'n MySQL db. Vergelijkbaar met mysql_fetch_assoc, maar ik heb ontdekt dat ELKE functie voor SQL een SLQException kan en moet kunnen throwen. Dat betekent dus (mijn analyse) dat ik dat elkeer keer moet afvangen. Dat doe ik nu.. Volgens mij is het niet netjes, maar nu weet ik niets anders...

[zneek]

Simon schreef op maandag 07 februari 2005 @ 07:56:
Ok, ik heb een Servlet waarmee ik bijvoorbeeld een gastenboek heb, en nu haal ik gegevens uit m'n MySQL db. Vergelijkbaar met mysql_fetch_assoc, maar ik heb ontdekt dat ELKE functie voor SQL een SLQException kan en moet kunnen throwen. Dat betekent dus (mijn analyse) dat ik dat elkeer keer moet afvangen. Dat doe ik nu.. Volgens mij is het niet netjes, maar nu weet ik niets anders...

Je hebt 1 servlet? Dan heb je ook 1 doGet of doPost methode waarin je bepaalt wat er gehaald en getoond moet worden, toch? Als je methode nou eens als volgt maakt:

Java:

public void doGet(HttpServletRequest request, HttpServletResponse response)
{
  try
  {
    // kies de goede actie
    // bouw een overzicht op
  }catch(SQLException e)
  {
    // stuur de gebruiker een foutpagina
  }
}

Binnen de try catch kies je de goede methode en roep je hem aan. Als er ergens een SQLException optreedt kom je in de catch en kun je de gebruiker een foutmelding geven. Zo vang je de exception op 1 plek, en al je methodes kunnen de SQLException simpelweg doorgooien.

[Gert]

Niet vergeten de connectie te sluiten in een finally {}