Ready to watch this entire course?
Become a member and get unlimited access to the entire skills library of over 4,900 courses, including more Developer and personalized recommendations.Start Your Free Trial Now
- View Offline
Author David Gassner explains how to choose a JDBC driver and connect to one or more databases. He also provides detailed instructions on reading, selecting, and updating data; calling stored procedures; managing data via JavaBean classes or with prepared statements; and working with metadata.
- Importing a MySQL database
- Connecting to databases
- Handling JDBC exceptions
- Looping through result sets
- Limiting the number of fetched rows
- Filtering data with prepared statements
- Calling stored procedures
- Inserting, updating, and deleting rows with prepared statements
- Using a persistent database connection
- Committing and rolling back transactions
Skill Level Intermediate
Just as with all Java programming, when something goes wrong in JDBC, you'll get an exception. In JDBC, most methods of JDBC objects throw a class called SQLException. SQLException is extended from the Exception class, and it inherits all of the tools that are a part of that class, such as getMessage and getLocalizedMessage, string representations of an error message, getStackTrace, and many other tools. But JDBC is all about databases, and so its special exception class SQLException is specifically designed to give you information about what's going on in the database.
SQLException adds these methods, getErrorCode returns an integer value which tells you what might have gone wrong. The Error code is unique to the particular database, so a numeric error code for MySQL won't be the same as for HSQLDB, and so on. And there's also a method called getSQLState which returns a five-character string. It's just like the error code. It's specific to the particular vendor and the particular database, but it's a string instead of an integer. To find out what these values mean, you'll need to look at the documentation for your particular database, MySQL, HyperSQL, SQL Server Oracle, and so on.
I'm going to be showing you how to look at the Exception object and get these values out, but you'll need to look at the documentation to find out what they mean. There are also methods called getNextException, setNextException, and iterator. When something goes wrong at the database level, many times it'll be a cascading set of exceptions, and these methods let you deal with those stacks of Exception information. Let's take a look at some code. I'm working in a project called JDBCExceptions, which is just like the projects that I have created previously in this video series.
It has the Utility class that lets me choose which database I want to work with, HSQLDB or MySQL, and then it executes a single statement and brings back a result. Before I run this code, I'm going to modify the SQL statement. So I'm more specific about the names of the columns that I'm getting from the database. I'll get rid of the asterisk and replace it with stateId and stateName, separated with a comma. These are the names of the actual columns in my states table in both databases.
I'll test the code and make sure that I have got it correct. I'm working with HSQLDB first, and I get back to my data, and then I'll change from HSQL to MySQL, and I'll run the code again, and I see that it works there too. So now I'm ready to introduce an intentional error. I'll start by getting the structure of my database wrong. Instead of states, I'll look for data from a nonexistent table named state. I'll run the application, and I get back an error object. Notice that this error object is specific to MySQL.
It has a pretty lengthy name, but it has the message Table 'explorecalifornia.state' doesn't exist. Now let's throw the same error for HSQL. I'll change my database type and run the code, and this time I get back a different error object, and it means the same thing, but the message is different, user lacks privilege or object not found. Now, to get more information out of this Exception object, I'm going to add some more detailed exception handling. I'll go to my Database Utility class, DBUtil, and I'm going to add a new method that I'll call processException.
I'll use the keywords public, static, and void, I'll name the new method processException, and I'll have it receive a single argument data typed as SQLException, and I'll name the object simply e. For now my only goal is to output the detailed information about the exception. So I'm going to add three error output lines. I'll use the System.err code template, I'll expand it, and then I'll duplicate it a couple of times. For the first line I'll output the error message. I start with a label Error message, and then I'll call e.getMessage.
Now this line of code would be the same regardless of what kind of Java exception I get. But now I'm going to process the methods that are unique to SQLException. I'll move the cursor to the second line, and this time the label will be Error code, and I'll append to that e.getErrorCode. And finally, I'll output the SQL state the string representation of the error. I'll save my changes to the DBUtil class, I'll go back to my Main class, and now within the catch block instead of outputting the error object in its raw form, I'll use my new utility method, DBUtil.processException, and I'll pass in the Exception object.
I'll run the code now, and I see my error message, my code, and MySQL state. So my goal here is to start showing you some of the differences between databases. I'm currently working with HSQLDB, notice the Error code and the SQL state -5501 and SQL state of 42501. I'm going to spell my table correctly, but now I'm going to misspell a column name. I save the changes and run the code, and I get back exactly the same Error code and SQL state that I did before.
So for HSQLDB, misidentifying a column or table returns the same exception. Now let's switch back to MySQL. I'll change my database type, I'll leave the code that's misidentifying the column name, I'll run the application, and this time I get back a different Error code and a different SQL state. That's expected because now I'm working with another database, and notice the SQL state is 42S22. Let's remember that. I'll go back to the code, I'll fix the column name so it's correct, and now I'll get the table name wrong.
I'll run the code again, and I get a different Error code and a different SQL state, 42S02. Now let's explore some other errors. One of the most common errors is a user authentication error. I'll fix my column names and my table name. I'll go back to my DBUtil class where I'm storing my user credentials, and this time I'll get my username wrong. I'm working with MySQL, and I get an Error code of 1045 and an SQL state of 28,000. Now let's switch to HSQLDB, and I get back another Error code and SQL state, -4001 for the Error code and 28501 for the SQL state.
What I'm trying to get across here is that the Error codes and SQL states are going to differ both from one database to another but also in their patterns within a database. One database like HSQL might use the same SQL state for two different but similar conditions, whereas another database might have distinct SQL states and distinct Error codes. The only way you'll know what these codes mean--as I have mentioned previously--is to look at the documentation for your particular database management system, but once you know what these error codes and SQL states mean, you'll be able to write more detailed and more useful exception handling logic in your own application.