Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Okay, so I have a very large project in Java that I have been working on for years (a game, if you must know).
Unfortunately, a mysterious message has started being printed. No matter the lengths of my searching, I cannot pinpoint the location of the message.
I know that you can override the println method, and I was curious if it was possible to have some sort of debugging info attached to the message being printed? Like the line or file it was printed from perhaps? I tried searching Google for this, but it is simply too detailed of a problem that I cannot find an answer.
Even worse, the message is very ambiguous. It is simply "-1".
Atleast I know now to use a proper logger instead of simply println().
In such a case you can use a conditional breakpoint in your ide. This is a really useful feature of ide that's not always well known.
You set a breakpoint and you want it to suspend the application only under some condition, in this case the parameter of the println method being your 'mysterious ufindable string'
In the case of Intelllij IDEA this would look like this:
You can do
new Exception().printStackTrace()
or similar without throwing the created exception to get a full stack trace for a current execution point. And there is no need to throw it. You may event save them into list for later processing.
This looks like a message from ArrayIndexOutOfBoundsException. Add breakpoint on this type of exceptions. Try this:
String[] arr = new String[0];
try{
System.out.println(arr[-1]);
}catch (Exception e){
System.out.println(e.getMessage());
}
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
Code of the if statement:
if (reponse.getStatus() >= HttpServletResponse.SC_BAD_REQUEST) {
LOGGER.error("Erreur lors de l'enregistrement de la trace technique - {}", reponse.getStatusInfo().getReasonPhrase());
}
Basically testing always consists of two parts:
preparing some input, so that your production code under test takes a specific path
verifying that the expected "things" happened
First one is easy: you have to somehow make sure that the response object that your production code is dealing with has the required status. How you do that, very much depends on context.
For the second aspect, that is probably hard. You see, the only action taking place is a (probably static) call to that error() message. If that is the case, then your only way of testing this would be to use JMockit or PowerMock(ito), because those two frameworks allow you to verify static method calls.
So, the real answer is:
figure for yourself how you can gain control over that response object
buy into using one of these mocking frameworks (not recommended)
rework your code so that it becomes testable without adding that (imho really really bad) dependency towards PowerMock(ito).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
My C++ teacher once told me that if I have to use a break to get out of a loop I didn't think enough about the loop condition.
So did she (very good teacher btw) just fail to mention that foreach loops are an exception to this rule (which I have generally found to be true) or is there indeed a way to get out of a foreach loop without using a break?
I am asking in general, but most interesting for me would be for Java or PHP.
Edit:
In case I haven't made this clear, I am wondering if there is a way to get out of a foreach-loop without using a break. Not sure what this whole commotion is about, what's wrong with that question?
foreach loops don't have any exit condition except for the implicit "when there are no more items to iterate over", so it is not possible to break out of them early while avoiding break without using some sort of a terrible hack (e.g. throwing exception, modifying the iterated collection, setting a boolean flag dontContinue and checking it in each iteration, etc.).
For ordinary loops, there indeed always is an obvious way to avoid using break (stop the current iteration using continue or if, and put the early exit condition into loop's condition), however whether such approach leads to a more readable code than using break is disputable.
In some cases, the reason for you to want to break out of a loop early is because you finished whatever task needed to be done, or found the needed item. In such cases, consider putting the particular functionality into a separate method and using return instead of break.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I don't mean every error in an individual program, I mean every error possible in Java 8. Is there somewhere in the Java Docs where you can find it?
It seems to me more of a research question rather than that of a solid implementation, but on any basis you have 2 lines of enquiry:
1) Any errors that can happen post compilation will only occur as instances of the Throwable type, if you want to track all of those down you'd need to include every single section of the runtime library (and any other possible user defined libraries included in your project) in a class that you intend to use to report them back to you or your running project program. You would then iterate over all of the currently defined classes using Reflection populating as you go a list with anything that returns true as instanceof Throwable - thats assuming you want all of the possible class names. The potential causes of those exceptions would only be hinted at by the documentation related to any given Throwable class.
2) On the other hand if you want all of the compile time-errors as well then you'll need to look in the source code for the Java compiler.
But in all honesty, the reason an exception is called an Exception is because it reports a fault based on an exceptional circumstance which you should be able to preempt during development. Anything faulty enough to stop a program working throws an exception and to catch anything Throwable without discerning the specific type is not something that should be considered for implementation - except perhaps if using a last chance saloon mentality (if my software hasnt resolved this over every condition I can forsee then it may be able to reset to base zero without falling over completely).
You can get a nice overview of these by looking at the package tree view of the java.lang package and navigate to Throwable (you can get to this view by selecting Tree in the navigation bar)
Throwable is the root of all errors and exceptions in Java. Notable Exceptions are
java.lang.Error: root of abnormal / fatal errors
java.lang.Exception: root of checked exceptions [*]
java.lang.RuntimeException: root of unchecked exceptions
[*] if extends Exception but not RuntimeException
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I'm writing a Java application that calls a method letsPlay. I want to see if the code works, and sout'ed to test if it's running or not. When I run the app, nothing is printed. Is it because Java doesn't sout anything, or is it a problem with my code?
private void letsPlay(boolean player1turn) {
if(player1playing && player1turn)
System.out.println("It is " + nameField1.getText() + "'s turn.");
}
One of the two:
(probably) player1playing or/and player1turn are false, causing the expression to be evaluated to false, so the statement won't be executed
output stream is directed to somewhere else and not to the console, to solve this you'll need to do something like:
System.setOut(new PrintStream(new FileOutputStream(FileDescriptor.out)));
The easiest way to find what's your problem is to debug your code. Use the debugger, it'll save for you time, much of it.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Bukkit's setData(data) and getData() are deprecated. But there's no replacement.
Bukkit/Spigot JavaDoc says this about setData():
Deprecated. Magic value
Why is that?
So far, the only way to do it is by using:
Block.setData(byte data);
So, you could do something like this:
myBlock.setData(2); // Set block data to 2
Although Block.setData() is deprecated, it still works, and will continue to work (deprecated methods in Bukkit are rarely removed, especially those for which there is no alternative).
I wish I could give a better answer, but that's the only thing that you can do, as of now.
The reason it is deprecated is because Minecraft is moving away from item IDs, and switching to item names, to make it easier to expand in the future. Where you used to have to run /give player 19, you are now supposed to run /give player minecraft:sponge (although the ID still works). The same thing is going to happen to data values, instead of giving someone 35:14, you now give them red wool.
To get rid of the warning given by using a deprecated method, put #SuppressWarnings("deprecation") above the deprecated method when you use it, or above the method in which it is used.
To set the type of the block, you could use:
Block.setType(Material type);
An example is:
myBlock.setType(Material.GOLD_BLOCK); // Set block to gold block
You could also use MaterialData, but no one really knows how to use it (as far as I know). It's one of the things included in the Bukkit API, but no one knows why.
The source of WorldEdit and most other big plugins look messy because they use a lot of interfaces. To the developers, it seems very organized, but to someone reading it, it looks very messy, unless you can actually visualize the hierarchy.