Claude Moore wrote:Have a look at Java Documentation. In a nuthshell, you should use unchecked exception when dealing with unrecoverable errors (a stack overflow, a connection to a DBMS dropped).
My personal taste: use checked exception as much as possibile in your business layer.
Paul Clapham wrote:Good to hear that!
As for "what happens under the hood", that isn't what you need to know. You need to know how variables work in Java. Here's a link to a pretty decent tutorial which tells you about that: Variable Scope in Java.
And then you say that some other code tries to use some other value, and it's null. Right?
Tim Holloway wrote:You confused me. I call "DML" SQL. Since basically, DDL is the part of "SQL" that isn't actually SQL and SQL is the part that was defined by Codd and Date.
Anyway, as I recall, auto-commit is on by default with MySQL and PostgreSQL and probably Oracle, SQL Server and DB2.
Realistically, saving stuff up to do a commit is something more common to programming than for just fiddling around with the database manually, so I'd expect auto-commit to be the default in general.
But I don't think that it's actually mandated anywhere. For that matter, I don't think that there's a standard that says a DBMS even has to have a command line interface application. Although it's going to be a lot less fun tweaking things without one.
sorry but, I got confused.
DDL is the part of "SQL" that isn't actually SQL
Tim Holloway wrote:Actually, while it might vary depending on which DBMS you're using, I've always seen DDL auto-commit. And actually, having to explicitly commit DDL sounds a bit problematic to me.
Paul Clapham wrote:
Kirk James wrote:Injecting static fields looks like a wrong usage of an OOP pattern (dependency injection), also static fields belong to a Class, not to an Object;
Those are both good reasons not to inject static fields, so I think you have the answer well-covered.