Is there a logic to identify if a code snipet would not compile or throw an exception at runtime?

[Marcelo Canaparro]

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.

LocalDate date = LocalDate.parse("2020–04–30", DateTimeFormatter.ISO_LOCAL_DATE_TIME);

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.

Could someone help me with some tips on that?

[Matthew Bendford]

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.

[Marcelo Canaparro]

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?

[Campbell Ritchie]

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:-

@Override
public String tostring()
{
   return "CodeRanch " + "is " + "brilliant.";
}
// ...
List<String> words = new ArrayList<>();
words.add("Campbell");;
words.add("123");
words.add(234);
// ...
List<Integer> numbers = new ArrayList<>();
numbers.add(123);
numbers.add(234);
numbers.add(new Integer(345));
numbers.add("456");

There are probably spelling errors in that code, but there are two three 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.
[edit]Get my counting right

[Norm Radder]

it is expected that you know the APIs method signatures.

Is that possible?  Who can do that?  Why memorize something that can easily be looked up?

[Campbell Ritchie]

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.

[edit]Correct three spelling errors.

[Marcelo Canaparro]

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.

[Paul Clapham]

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.

[Campbell Ritchie]

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?