I've seen questions answering this with Visual Studio
vs-2008-addon-to-temporarily-disable-remove-all-catch-block
how-to-temporarily-deactivate-all-try-catch-blocks
but can't find anything regarding either Java or Eclipse. Does this feature exist, or is there some type of workaround I can use instead?
I don't know of any specific way to disable catch blocks, but what you could try is having eclipse automatically break on exceptions.
There is no standard feature to do so (except rather tricky byte code rewriting).
You may, however, tell Eclipse to set a breakpoint when a given exception is thrown. The easiest way to do so, is to paste the troublesome stack trace to the stack trace panel in the Console, and click the exception name (not the lines refering to code). This will open the appropriate dialog.
I will give the same answer that Mr Skeet gave in the second link.
Why would you want to do this?
If you are having problems with error handling hiding true errors, you should make sure the error handlers log properly and control the logging levels. I'm thinking something like Log4j.
The only valid reason someone would need to do this would be if they were maintaining someone else's lousy code with a ton of catch (Throwable t) {}. In this case you have my condolences.
PMD will scream about this kind of thing, and except in very specific circumstances it is best to rip out any eating error handlers, or at least replace them with logging.
Related
My java code has these error squiggles. What do they mean and how do I disable them?
Mouse Over Drop Down 1
Mouse Over Drop Down 2
What do these mean? What does the software suggest me to do?
PS: I'm a complete newb
Hints, no error. For proposing code changes, and SonarLint: code style warnings.
Here it suggests (wrongly so) to replace System.out by a shorter final PrintWriter, say out, so you need only to use out.println(...). That is not normally done.
But a similar rule states that one should use a Logger instead.
For the main: new Hello().execute(); and then in a separate non-static method (execute) do the code you wrote in main.
SonarLint: code style checker, named after the C lint tool to find "lint" in the code, dubious code pieces, like unitialized variables, dangerous lossy conversions and such.
Writing to System.out (the console) is not good style in a web server or a GUI desktop application, hence the advice is to use a Logger for logging interesting information, possibly to the console, but also possibly to a log file.
You should especially as a beginner not disable the linting extension.
Ignore the squiggles, only from time to time look at them.
One can also disable specific SonarLint rules one finds dumb.
I disabled the extension "Language Support for Java(TM) by Red Hat" . This was the extension that did the code linting. Now the squiggles are gone.
Can I get a scheme with my method calls tree?
I want to see tree of my method calls, with classes as levels.
Does tools like this exist?
Actually, a stack trace pretty much would already seem to cover your requirements. If you are asking this in the context of catching an exception, then logging the exception would record the stack trace of method calls leading up the method where the actual problem occurred.
If you're not asking this in the concept of catching an exception, then you can still run your code in debug mode and attach the IDE. Then, you should have visibility into the series of method calls behind each method being executed.
You can look for open call hierarchy or show references in the workspace by right clicking on the method, if you are using eclipse.
You are looking for Callgraph - Doxygen can do that, with JavaDoc you may try this project on Github
You could just also right click the method your interested in and click open call hierarchy or show references in the workspace project or working set. These are default with eclipse.
I'm working with a legacy Java app that is new to me so one way to figure out how it works and find things easier, I have thought would be to be able to get the full stack trace after I perform actions, so as to be able to see which classes are being used based on a particular UI action. I had thought this was possible in the debugger but it seems that it only works if I insert a breakpoint and in this case part of the purpose of this is so that I don't have to know what's being called to be able to insert the breakpoint first (as this would help tell me that).
I apologize if this is a basic question, I have searched on this but I'm not finding the correct answer.
This doesn't directly answer your question, but maybe it will solve your problem better. Take a look at BTrace. It lets you instrument a running Java app and insert some basic code of your own. You could, for instance, have it write out entire method call chains to help you find your way through the app. It's somewhat similar to AspectJ, but with an entirely different purpose and requiring no change in the project source:
"BTrace is a safe, dynamic tracing tool for Java. BTrace works by dynamically (bytecode) instrumenting classes of a running Java program. BTrace inserts tracing actions into the classes of a running Java program and hotswaps the traced program classes."
A few suggestions:
Some profilers will allow you to walk from any particular method up (and sometimes down) to see what's calling and being called. I've found this surprising informative about flow, even in apps I thought I knew well.
For understanding the mainline flow, I don't think there's a better substitute for working interactively with a debugger. It will lead you into learning other important things. Not what you wanted to hear, I know. This presumes that you can rapidly restart the app when you miss a key off-ramp.
Reverse-designing large legacy apps is the one place where I use UML fairly regularly. There's too much to keep in my head to form a good big picture. If you have a UML tool that will do reverse-engineering, load it up with the app, then probably prune down hard on the classes you don't care about, because they are trivial or obvious. Arrange the diagrams in a way that helps you understand. I've used Together, Magic Draw, and Visual Paradigm in this way. Together worked the best - but it was a decade ago.
When you are in the debugger perspective, you will see a view showing the launched processes. In that view you can tell it to pause all threads of a process. Once stopped, you will be able to browse through threads to see what they are all doing. To try to catch what a particular action is doing, you would have to start the action and then quickly pause all threads.
You could always run the application with the VM arg of -verbose:class. You could then watch the console output and see what classes the VM is loading when you perform a particular action. This could possibly give you a starting place for where to place breakpoints. This won't always work depending on the scenario, but may be helpful.
Another trick you can use is to figure what classes you know that have to be involved in the code path you are trying to trap. For instance, you mentioned that it's a Java EE web app and therefore the action is likely some kind of a servlet interaction (at some level). I don't have the API in front of me, but you can place a breakpoint on the method in the response object where the output stream is retrieved. Once that breaks, you will know the code that's trying to service the request.
You can always see where a method is called by clicking "Open Call Hierarchy" from eclipse (left click on the selected method or CTRL+ALT+H ). Also, you always can inspect where a method/class is defined by clicking "Open Declaration" (left click on the selected method/class or F3).
Is there a way to make Eclipse show up in its Console the "top" exception instead of just printing all the stack trace and leaving me always with the screen filled with basically useless stuff? Here's a picture:
There are basically 2 things I might want to know in 99% of the times when there's an exception: it's name+message plus in which method it ocorred. None of them is visible without having to scroll up.
This is how I feel the data should be shown:
Is there a way to change this Eclipse's behaviour?
I know of no Eclipse feature that will do this.
I disagree that the IDE should do this. There's no way for the IDE to know what information in the stacktrace is useful or useless. Scrolling the console to the supposedly useful part of the stacktrace based on some heuristic might help you a little bit today, but tomorrow it might hinder you a lot. And the problem / danger is likely to be worse if you start folding or editing the stacktrace displayed in the console window.
Use the scrollbar Luke!
If you really think this would be a good idea, implement it and submit a patch to the Eclipse developers. Or create a plugin. Or use a different IDE.
By the way, the screenshot you included in your comment does not show an IDE scrolling a console window. Rather it is showing an exception that has actually been delivered to the IDE as-is. Eclipse can do this too ... to some degree ... as illustrated by the JUnit test view, the Error view and so on. But this doesn't work if the stack trace has been rendered as text and written to a console window. (For a start, the text format of a stack trace is not actually specified.)
I don't think there is a way in Eclipse to do this.
But I think the IDE actually has nothing to do with this. It is the JVM that is printing that output to the console since your program isn't catching the exception. If you ran it from command line, you would see the same output.
I think the program should handle the exception and print the desired level of information to the console.
Indeed, the IDE has nothing to do with this. And you might want to rephrase that opinion as sometimes the useful information is not always the last executed line, but somewhere deeper in the stack trace (ex: an invalid value is passed to a method, down to the nth level where the exception occurs.)
Eclipse can't change this behavior as this is a run-time behavior of the JVM; when the exception is not catch, System.err is used to output the stack trace. You can change this by replacing the error output stream.
The PrintWriter that you set could keep the original copy of System.err and simply discard anything you don't care (i.e. anything matching "^\s*(java(x?)\.).*", or something) But the work around is not worth the trouble.
The better solution would be to catch and handle your exceptions and output something useful instead. The Java API is pretty explicit when some method throws an exception. There should be no surprise there.
Or another solution would be to avoid exceptions at all and be glad that Java prints a much useful stack trace to begin with and help you debug your application. Many language actually don't do that (or just not as good). If and when you deploy an application to a client, you'll actually be glad that the user sends you the complete stack trace instead of just a one-liner where the exception occurred.
You can use an eclipse plugin like grepclipse or GerpConsole to filter console's output with regular expresions.
This is a follow-up question to 1832203. I'm making it a new question as well, because it seems that posting an answer to a question doesn't change its position on the java page and so I'm worried that it won't get seen. Apologies if I've just stepped on some etiquette toes.
I'm an IntelliJ newbie -- started using it two days ago and I'm absolutely head-over-heels in love! One of the things I adore is the code inspections. However...
In one of my classes I often create exceptions without throwing them. If I can't turn off (or downgrade) the inspection warning for this then I can see I'm going to end up ignoring inspections on at least that file (if not the entire project), which would be a real pity.
I've done a search in the inspection settings for "exception", and found nothing that relates exactly, so I turned them all off just to see, and it's still doing it (even after a rebuild...BTW when are inspections redone? at save? at rebuild? ???), so I would really like some help on how to make this one into an info/typo level -- which I can then ignore.
Using the free version, if that makes any difference
TIA to all those experienced IntelliJ warriors out there!
Press Alt+Enter to show inspection popup, then press Right Arrow to see available options. You'll see there options to suppress this current instance of warning, for this class or completely turn it off.