I've noticed an unexpected behavior in an object used in this really complicate framework.
What I want is that the debugger stops (like with breakpoints) every time that the object appears in an instruction, without manually add breakpoints in all the instruction where it is used/appears.
Can I do something like this in IntelliJ?
Field Breakpoint is what you are looking for.
Read breakpoint type overview to get an overview of the different breakpoint types.
Furthermore, it is possible to put a condition on a breakpoint - read configure breakpoints.
I'm working through a project in Visual Studio 2013 and I got the following error: "Visual Studio cannot start debugging because the debug target is missing". I've tried changing the build output path under Project -> Properties but it still doesn't work. So what gives?
Check your code and make sure you aren't missing a curly bracket anywhere. If one was accidentally deleted, moved, or misplaced, it causes this error among MANY others depending how critical the placement of the curly bracket is in your project.
^
I just recently had this problem in a project I was working on. I had highlighted to delete a section of code, and it took out a curly bracket with it. Unnoticed by myself, it took me a few days to finally realize that's what happened.
You won't get an error from the bracket missing, so it's stupid in itself and impossible to find at times.. but I had 51 errors, 7 warnings, and that "can't start debugging because the debug target is missing" error when I attempted to run the program, after the curly bracket went missing.
It's not to say that you might not have another issue going on that is causing this, but the curly brackets can wreak havoc if they aren't precisely placed. So it's worth checking into that before getting too extreme in options to "fix" the start error.
For future reference if this problem occurs again. Good luck.
Possible VS 2019 Solution
Right Click on Solution Properties
Go under Common Properties> Startup Project
Set Single startup project
Right Click on Project Properties
Click Application
Set Application Type to Windows Forms Application or Console Application or Windows Service
Click Startup Object
Set to Anything Other than (None)
Left Click on Project Properties
Set Copy Build Output to Output to True
Then Run
Hopefully that works for you
I am using Xcode 6 (GM, I didn't download betas), and I am developing apps for iOS 7+. For all my projects, I just opened the same projects I used to work on in Xcode 5.
In the Breakpoint navigator, I have the All Exceptions breakpoint on. It is set to Break: On Throw. Now, each time I run my app (whether on a device or in simulator), it stops execution on the line return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); in the main() function.
If I press Play to continue program execution twice, the program runs fine. So this doesn't prevent me from working, but it is annoying to have to manually play the execution each time and reset my editors.
I like the behaviors I have set up in Xcode (taking the current editor to where the execution has paused), and having that All Exceptions breakpoint is important IMO. (So I don't want to change those)
By running the same code, with the same environnements, for an iOS 7 target (again, device or simulator), the exception is not thrown.
Any clue what could cause this strange behavior?
As stated in the comments, you should turn off catching the C++ exceptions by editing your All Exceptions breakpoint.
In order to do that, right click on your breakpoint and change Exception from All to Objective-C:
Exceptions in C++ code are part of normal app functionality. However, exception breakpoint is not catching unhandled but every raised exceptions, even when they're handled correctly later on, hence the stop in execution.
TLDR; In my case the cause of problem was missing fonts.
I also had this problem. While #Johnnywho is correct that leaving Exception Breakpoint for Objective-C only, stops the unwanted behaviour, it still does not explain what is the real cause, why does it run without exception on iOS7 and why does this happen only on some projects.
That's why I went on and dissected one of my projects in which I had this problem, until the point where I was able I found the cause. I suppose that there could be more than one cause for this behaviour, but in my case that was missing custom fonts.
Quick way to test it:
Start a new single view project
Enable breakpoint on all exceptions, including C++ (Breakpoints / + / Add Exception Breakpoint)
Drag into the project some custom font (allow copying and check the target to add it to)
Add a label to the view in the main view controller
Choose the custom font for your label (on Xcode 6+ it should show in the font picker as soon as you drag it into the project).
Run the app and confirm that you see the label in your custom font (it seems that we don't need to add the font file name in Info.plist for the key "Fonts provided by application" anymore, if the custom font has been used in a storyboard of xib of the app).
Now remove the custom font from your project (either by unticking target relationship or by removing it in target settings / Build Phases / Copy Bundle Resources)
Delete the app from your device or sim (to delete the font file from the app bundle)
Product / Clean
Run the app again (now the label still has the reference to the custom font but the app does not have the file for it). You should notice the mysterious exception if you run on iOS8.
Run the app on device with iOS7 or sim with iOS7 (you'll need to change the iOS Deployment Target to iOS7 for that). Although the label won't show the custom font, there won't be an exception.
Add the font file back to the target and the breakpoint does not stop on run anymore.
So my conclusion is that on iOS8 the missing fonts cause C++ exception while on iOS7 they don't, hence the breakpoint trigger.
Similar exception (and breakpoint trigger) can also be caused by incorrectly written font file name in Info.plist file under the key "Fonts provided by application".
Just summarized previous answers which helped me to fix it.
Problem: When you add custom font and then apparently delete (replace) it, somewhere in project is still his reference and the breakpoint stops several times at main C++ lib breakpoint stops in iOS 8.
Solutions
1) Find in project and delete (replace) all references to those fonts. Might in some nibs, submodules, etc…
2) If you can’t fix everywhere (e. x. read-only libs use them) or problem still exists after solution 1 , add those old fonts back to project
3) Ignore it - It is C++ lib so change breakpoint exception from “All" to "Objective-C" only
Xcode 9, sometimes there are exceptions that are thrown but iOS is catching it gracefully. This will help
source
for my case, it was a user-defined attribute in nib
I had a same issue, the issue was i have added some interface files from other project which has different font in it. Just find them and remove.
I am using the JDeveloper IDE to build a Java application and, at some point, my error pane has stopped appearing to display compile errors.
When I alter the code to intentionally produce errors during compilation (such as deleting a required parenthesis or brace, etc), I will be informed that there were errors during compilation within the "Messages - Log" window. However, I cannot find the window which describes the errors occuring and their location in the code.
Basically, I just want to access the window that lists the errors found, what class they are located in and what line or method they are in. How do I do this?
Try from menu Window > Reset Windows to Factory Settings.
In Eclipse, when I make any code changes it automatically shows all compilation errors in the workspace in a console. It seems like in IntelliJ I have to make/build the project in order to see any compilation errors. Is there a window/tab to show all compilation errors?
Nowadays you have the same option as in eclipse to have automatic builds when you save.
Edit
Any changes in the editor will now trigger a compilation either when Ctrl+s is pressed or after a short interval.
This first image will show a main method and a class with a simple print method. No compilation errors.
In the next image I have removed the parameter message in the print method. That's the only thing I did, I did not even save I just waited a couple of seconds. And then suddenly the compilation error is shown below because the caller of the method has now supplied too many arguments.