I am studying for the certification using the Selikoff study guide, and I noticed that in a lot of questions there are two possible answers: "The code does not compile" and "the code throws an exception at runetime"
Most of the time I can find the problem in the code but am not sure which of the two will happen.
In the example above, I know that the wrong formatter is used and something bad will happen but only running the code I realize that it compiles, this is bad for the certification exam.
I need some kind of logic to follow and identify cases where compilation will catch the problem or not.
Well, basically the compiler does couple of runs through the source, like it first tokenize the source, then checks if it can resolve anything, if there're some lines out of place, count the brackets to add up ... the list goes on.
Same goes for evaluate source by hand. First you would have to know if a class LocalDate even exist. Then you have to check if it has a static method parse() with the number and types of parameters by looking at the doc. This way you can figure out if the code would even actually compile in the first place. If you end up in "that code won't compile" you don't have to care about "it maybe throw an exception at runtime", as the latter could only happen if the source compiles.
Also looking at the doc you may be able to figure out if the given inputs match up - like if a "year-month-day" is an iso local datetime.
As for try to figure out if some will work it's like you try to be a compiler (or at least a validator) and runtime in your head at once. I don't know how much time you have in an exam or to what resources you have access to, but I guess one has at least access to the SE API doc.
Unfortunatly accessing the documentation is not allowed, it is expected that you know the APIs method signatures.
I think maybe it is safe to say the compiler can only check syntax and parameter type matching, the rest ends up compiling and succeptible to throws.
Can I rely on that line on thought?
Marcelo Canaparro wrote:Unfortunatly accessing the documentation is not allowed. . .
Well, you will have to learn some of the commoner API members for the exam.
. . . it is safe to say the compiler can only check syntax and parameter type matching . . . Can I rely on that line on thought?
No. The Java Language Specification (=JLS) gives lots of circumstances when compilation must fail. Most of those are incorrect syntax but some are logic errors, e.g. use of the keywords static and abstract together. Other compiler errors occur because you instructed the compiler to throw an error:-There are probably spelling errors in that code, but there are twothree places where I have instructed the compiler to throw an error rather than run the code, and suffer a method which doesn't work or an exception. There is also code which will compile but issue a warning. I challenge you to get that code to compile and cause an exception to be thrown at runtime. I am old enough to remember when similar code would compile without warnings and errors would occur at runtime.
As you said earlier, you will get compile time errors if you use incorrect types or if you use correct datatypes whose definition in inaccessible, your code will fail to compile.
I think you should write lots and lost of different code and introduce potential errors into it and see what happens. You will lose marks if you say code won't compile if it throws an exception, or vice versa.
Get my counting right
The exam may require people to know some details of the API, but I would only expect to learn only a few methods off by heart. After passing the exam, I would go back to doing the sensible thing: look them up as you said, Norm.
I challenge you to get that code to compile and cause an exception to be thrown at runtime
Damn, I was not aware that the Integer constructor was deprecated. I used valueOf and parseInt because that was how I learned to do it, never actually stopped to think about it.
But am I correct assuming the compile is unable to validate code logic? Because if that is true, it is safer to assume that if java syntax and class types are being respected a compiler error should not occour.
Marcelo Canaparro wrote:But am I correct assuming the compile is unable to validate code logic?
Of course. If you wrote "if (value > target) ..." and you should have written "if (value < target) ..." how should the compiler know that? There's an old, old joke about how we should all be using DWIM compilers (where DWIM = Do What I Mean) but those beasts don't exist yet.
Another challenge: look at my post from a few minutes ago. Suggest four ways the compiler might throw an error without there being a syntax error in that code or similar. How many logic errors can you find or introduce into that code without the compiler noticing? [addition]...or without a novice programmer noticing there is a difference?