I want to test a method where the following lines appear:
try (Connection connection = dataSource.getConnection()) {
((org.postgresql.PGConnection) connection).addDataType("geometry", Class.forName("org.postgis.PGgeometry"));
((org.postgresql.PGConnection) connection).addDataType("box3d", Class.forName("org.postgis.PGbox3d"));
try (Statement statement = connection.createStatement()) {
/*
* 4326 is the ID of a format in which the longitude and latitude values should be
* retreived.
*/
String sqlQuery = "SELECT ST_Transform(way, 4326) FROM planet_osm_line WHERE (highway='footway' OR highway='steps');";
ResultSet resultSet = statement.executeQuery(sqlQuery);
while (resultSet.next()) {
PGgeometry geom = (PGgeometry) resultSet.getObject(1);
LineString line = (LineString) geom.getGeometry();
Point[] wayPoints = line.getPoints();
pointList.add(wayPoints);
}
}
} catch (SQLException | ClassNotFoundException e) {
throw new OpenStreetMapDAOException(e.getMessage(), e);
}
those lines force me to catch a ClassNotFoundException, i.e. the call of Class.forName("name") does so.
The catch case for the ClassNotFoundException is never reached in my tests since these classes are always present. Is there a way to test my catch block?
As org.postgresql.PGConnection seems to be an interface, you could try to mock it via Mockito or a similar mocking framework.
org.postgresql.PGConnection connection = Mockito.mock(org.postgresql.PGConnection.class)
Mockito.doThrow( ...your exception here...).when( connection ).addDataType("geometry", Class.forName("org.postgis.PGgeometry"));
With these two lines you are creating a mock object for your connection which you can then use in your method. This mock object will throw the given exception when that method is called with these parameters.
I refactored the code from my question till I ended up with the following method for the critical part, i.e those Class.forName("some.class.name") calls:
Statement createStatement() throws SQLException, ClassNotFoundException {
Connection connection = dataSource.getConnection();
((org.postgresql.PGConnection) connection).addDataType("geometry", Class.forName("org.postgis.PGgeometry"));
((org.postgresql.PGConnection) connection).addDataType("box3d", Class.forName("org.postgis.PGbox3d"));
return connection.createStatement();
}
In my unit tests I then used
when(dao.createStatement()).thenThrow(ClassNotFoundException.class);
which finally solved my problem.
Related
I have come up with the following utility class:
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
public class MySqlConnection
{
private static String dbUrl = "jdbc:mysql://localhost:3306/database";
private static String dbUsername = "root";
private static String dbPassword = "mysql";
public static Connection getConnection()
{
Connection connection = null;
try {
Class.forName("com.mysql.jdbc.Driver");
connection = DriverManager.getConnection(dbUrl, dbUsername, dbPassword);
} catch (ClassNotFoundException e) {
System.out.println("Could not load JDBC driver: " + e.getMessage());
} catch (SQLException e) {
System.out.println("Could not connect to DB: " + e.getMessage());
}
return connection;
}
}
The problem is: I do not want to return null from my method, because by doing so I force my callers to do a if (connection != null) {...} check every time they open and want to use a connection. I find these null checks to be error prone and want to avoid them at all costs. What other approach could I follow to manage database connections in my application?
First of all, as of JDBC 4.0 / Java 6, calling Class.forName() is no longer necessary. (See is Class.forName() necessary)
Next, don't bury the exceptions. Throw them up the stack, and let the callers decide how the exceptions should be handled. Depending on when getConnection() is being called you might want to:
Display an error popup box to the user
Try a different database for a connection
Run a script to try and check the status of the database and attempt to restart it if it appears to be down
Retry getConnection() completely
My point being, don't be afraid to throw Exceptions up the stack and let the caller handle the Exception appropriately.
All that being said, your getConnection() method should just need to store your DB URL, username, and password.
public class MySqlConnection
{
private static String dbUrl = "jdbc:mysql://localhost:3306/database";
private static String dbUsername = "root";
private static String dbPassword = "mysql";
public static Connection getConnection() throws SQLException
{
return DriverManager.getConnection(dbUrl, dbUsername, dbPassword);
}
}
Realistically, getConnection() will very very rarely throw an SQLException. The only scenario I've ever seen it throw an SQLException is because credentials were incorrect or the database was down.
You can throw an exception in your original code upwards, and then have to deal with a possible exception every time you would want to get a connection. Granted, you will not have null issues, but this could end up being more work. However, it does make it very explicit that you have to handle the connection not working, and this could be clearer than simply returning a null.
Refer these two questions , Should a retrieval method return 'null' or throw an exception when it can't produce the return value? and How to show if a method may return null
that should clear things a bit.
You can't avoid returning a NULL if you can't produce desired object ( In some cases, we have an option to return EMPTY objects but that is not applicable to JDBC connection object ) - All you can do is properly document your methods.
You should also avoid doing Sysouts and let the caller know about errors to expect by adding throws to your method and by re throwing exceptions. You have an option to wrap your exceptions to something more useful ( specific to your application ) before re throwing.
Also , do explicit NULL returns from your catch ( return NULL; ) instead of relying on last return statement - return connection; . There is no point of not returning immediately if not wiling to eat Exception and continue.
Lastly, you should try to use #Null and #NotNull annotations to properly document your methods.
Below is my Java program. I am calling a PLSQL procedure to update the Employee name. I turned off the commit in the PLSQL code so that I can do the commit and rollback from Java code. But even after I turned off the auto commit and doing explicit rollback, still the details are updated in the table.
How? I have no idea, please help.
Here's my Java code. In PLSQL, it just read the value and does an update statement . No commits.
public class TestCommit {
public static void main(String[] args) throws SQLException, IOException {
CallableStatement callableStatement = null;
Connection conn = null;
try {
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
conn = DriverManager
.getConnection("jdbc:oracle:thin:testuser/testpwd#//testdb:1521/testbx");
conn.setAutoCommit(false);
String sql = "{call testpkg.saveemployee(?,?)}";
callableStatement = conn.prepareCall(sql);
callableStatement.setString("name", "spider");
callableStatement.setString("id", "A101");
callableStatement.executeQuery();
conn.rollback();
} catch (Exception ex) {
ex.printStackTrace();
} finally {
// Close the statement
callableStatement.close();
// Close the connection
conn.close();
}
}
}
edit: PLSQL
CREATE OR REPLACE PROCEDURE saveemployee(
name IN employee.ename%TYPE,
id IN employee.eid%TYPE)
IS
BEGIN
UPDATE employee SET ename = name WHERE eid = id;
END;
My bad, I was calling a wrong procedure, there were two versions of the same procedure in two different packages,
one has the commit , the other one doesn't have the commit. I was calling the one that had the commit.
Now that the commit is removed from both procedures, my code seems to work now.
This is how I implement each jooq query that i want.
UtilClass{
//one per table more or less
static void methodA(){
//my method
Connection con = MySQLConnection.getConexion(); //open
DSLContext create = DSL.using(con, SQLDialect.MYSQL); //open
/* my logic and jooq querys */ //The code !!!!!!!
try {
if ( con != null )
con.close(); //close
} catch (SQLException e) {
} //close
con=null; //close
create=null; //close
}
}
Am I overworking here? / Is it safe to leave the Context and Connection Open?
In case it is safe to leave it open I would rather work with 1 static field DSLContext per UtilClass (and only the commented section would be on my methods). I would be opening a connection for each UtilClass since I am encapsulating the methods per table (more or less).
DSLContext is usually not a resource, so you can leave it "open", i.e. you can let the garbage collector collect it for you.
A JDBC Connection, however, is a resource, and as all resources, you should always close it explicitly. The correct way to close resources in Java 7+ is by using the try-with-resources statement:
static void methodA() {
try (Connection con = MySQLConnection.getConexion()) {
DSLContext ctx = DSL.using(con, SQLDialect.MYSQL); //open
/* my logic and jooq queries */
// "ctx" goes out of scope here, and can be garbage-collected
} // "con" will be closed here by the try-with-resources statement
}
More information about the try-with-resources statement can be seen here. Please also notice that the jOOQ tutorial uses the try-with-resources statement when using standalone JDBC connections.
When is DSLContext a resource?
An exception to the above is when you let your DSLContext instance manage the Connection itself, e.g. by passing a connection URL as follows:
try (DSLContext ctx = DSL.using("jdbc:url:something", "username", "password")) {
}
In this case, you will need to close() the DSLContext as shown above
I have the followiing situation: I have a java code which is connected with a database (MySQL). When i am running the java code from eclipse and taking data from database, everything is ok.
But when i am running java code from html code as Applet, it throws Null Pointer Exception and i detect that problem in this case occur to the following java code:
private Connection getConnection() throws SQLException{
try {
Class.forName("com.mysql.jdbc.Driver");
String name="jdbc:mysql://localhost:3306/sensors_data";
String username="root";
String psw="11111";
conn = DriverManager.getConnection(name,username,psw);
} catch(Exception e) {
e.printStackTrace();
}
return conn;
}
The object "conn" is null.
Well, if DriverManager.getConnection() throws an exception, you're printing out the exception but then returning conn anyway. You should probably be letting the exception propagate to the caller - after all, it's not like the caller now has a connection they can use.
(You're also catching any exception, instead of just SQLException, which is a bad idea.)
I wouldn't expect to be able to connect directly to a database from an applet though - I can't remember the exact restrictions on applet network connections, but that may well be the problem. Where is the database running compared with the web server? If it's not on the same host that the applet is published from, I wouldn't expect it to be able to make a connection at all without special permissions. (Trying to connect to localhost is particularly unlikely to work, I suspect.)
You should be able to see the exception thrown by DriverManager.getConnection in your debug log of course - that should be the first port of call, as well as fixing the exception handling.
Replace localhost with the machine name on which the database is located then try again.
The problem is that you should return the conn inside the try{} thread. Or, you can create a connection variable as a class field, and then assign the conn value to the connection inside the try{} tread, then problem will be solved hopefully.
public static Connection conn1 = null;
public static Connection getConnection(){
try {
Class.forName("com.mysql.jdbc.Driver").newInstance();
Connection conn = DriverManager.getConnection
("jdbc:mysql://localhost/?user=root&password=root");
if(conn != null){
System.out.println("Connect database successfully.");
conn1 = conn;
}
else System.out.println("Connection failed...");
return conn;
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
hey all, I'm new to Java and was wondering if I define a method to return a database object
like
import java.sql.*;
public class DbConn {
public Connection getConn() {
Connection conn;
try {
Class.forName("com.mysql.jdbc.Driver").newInstance();
if(System.getenv("MY_ENVIRONMENT") == "development") {
String hostname = "localhost";
String username = "root";
String password = "root";
}
conn = DriverManager.getConnection("jdbc:mysql:///mydb", username, password);
return conn;
} catch(Exception e) {
throw new Exception(e.getMessage());
}
}
}
if the connection fails when I try to create it what should I return? eclipse is telling me I have to return a Connection object but if it fails I'm not sure what to do.
thanks!
UPDATED CODE TO LET EXCEPTION BUBBLE:
public class DbConn {
public Connection getConn() throws SQLException {
Connection conn;
String hostname = "localhost";
String username = "root";
String password = "root";
Class.forName("com.mysql.jdbc.Driver").newInstance();
if(System.getenv("MY_ENVIRONMENT") != "development") {
hostname = "localhost";
username = "produser";
password = "prodpass";
}
conn = DriverManager.getConnection("jdbc:mysql:///mydb", username, password);
return conn;
}
}
If an exception is thrown, there is no normal value returned from the method. Usually the compiler is able to detect this, so it does not even pester you with "return required" style warnings/errors. Sometimes, when it is not able to do so, you need to give an "alibi" return statement, which will in fact never get executed.
Redefining your method like this
public Connection getConn() {
Connection conn = null;
try {
Class.forName("com.mysql.jdbc.Driver").newInstance();
if(System.getenv("MY_ENVIRONMENT") == "development") {
String hostname = "localhost";
String username = "root";
String password = "root";
}
conn = DriverManager.getConnection("jdbc:mysql:///mydb", username, password);
} catch(Exception e) {
// handle the exception in a meaningful way - do not just rethrow it!
}
return conn;
}
will satisfy Eclipse :-)
Update: As others have pointed out, re-throwing an exception in a catch block the way you did is not a good idea. The only situation when it is a decent solution is if you need to convert between different exception types. E.g. a method called throws an exception type which you can not or do not want to propagate upwards (e.g. because it belongs to a proprietary library or framework and you want to isolate the rest of your code from it).
Even then, the proper way to rethrow an exception is to pass the original exception into the new one's constructor (standard Java exceptions and most framework specific exceptions allow this). This way the stack trace and any other information within the original exception is retained. It is also a good idea to log the error before rethrowing. E.g.
public void doSomething() throws MyException {
try {
// code which may throw HibernateException
} catch (HibernateException e) {
logger.log("Caught HibernateException", e);
throw new MyException("Caught HibernateException", e);
}
}
You should just eliminate your entire try/catch block and allow exceptions to propagate, with an appropriate exception declaration. This will eliminate the error that Eclipse is reporting, plus right now your code is doing something very bad: by catching and re-throwing all exceptions, you're destroying the original stack trace and hiding other information contained in the original exception object.
Plus, what is the purpose of the line Class.forName("com.mysql.jdbc.Driver").newInstance();? You're creating a new mysql Driver object through reflection (why?) but you're not doing anything with it (why?).
Never, ever, ever use a generic exception like that. If you don't have a ready made exception (in this case, an SQLException), make your own exception type and throw it. Every time I encounter something that declares that it "throws Exception", and it turns out that it does so because something it calls declares "throws Exception", and so on down the line, I want to strangle the idiot who started that chain of declarations.
This is exactly the situation where you should let the exception propagate up the call stack (declaring the method as throws SQLException or wrapping it in a application-specific exception) so that you can catch and handle it at a higher level.
That's the whole point of exceptions: you can choose where to catch them.
I'm sorry, but you shouldn't be writing code like this, even if you're new to Java.
If you must write such a thing, I'd make it more like this:
public class DatabaseUtils
{
public static Connection getConnection(String driver, String url, String username, String password) throws SQLException
{
Class.forName(driver).newInstance();
return DriverManager.getConnection(url, username, password);
}
}
And you should also be aware that connection pools are the true way to go for anything other than a simple, single threaded application.
Try this one
public ActionForward Login(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) {
MigForm migForm = (MigForm) form;// TODO Auto-generated method stub
Connection con = null;
Statement st = null;
ResultSet rs = null;
String uname=migForm.getUname();
String pwd=migForm.getPwd();
try{
Class.forName("oracle.jdbc.driver.OracleDriver");
con=DriverManager.getConnection("jdbc:oracle:thin:#localhost:1521:XE","uname","pwd");
if(con.isClosed())
{
return mapping.findForward("success");
}
//st=con.createStatement();
}catch(Exception err){
System.out.println(err.getMessage());
}
return mapping.findForward("failure");
}