Enabling Debug Exceptions from OpenCV in VS2012 c++/cli

Question

I am using VS2012 c++/cli on a Win 8.1 machine, 64 bit with OpenCV 2.4.9.
One issue I have is catching exceptions issued by OpenCV in try/catch blocks.
When I run my app in Debug mode from within VS2012, I never get an OpenCV exception.
However, when I run the exe generated by VS2012 in Debug mode outside of VS2012 (by just navigating in Explorer to the exe), exceptions are being generated by OpenCV and caught by mt try/catch blocks.
What do I need to set so that I can see these exceptions when running in Debug mode form within VS2012?
Any help greatly appreciated.
Regards,
James

Answer 1

So zsh is telling you that the command didn't work, since it claims that there is no such file or directory. I had a lot of trouble with getting the echo command to work, as well. I found that if out of these lines:
export CONFIG_CFG80211_DEBUGFS=y
export CONFIG_MAC80211_DEBUGFS=y
export CONFIG_ATH_DEBUG=y
export CONFIG_ATH9K_DEBUG=y
export CONFIG_ATH9K_DEBUGFS=y
If the first and second line above were not uncommented in the config.mk file, I couldn't leave the last line above uncommented as well, or else makepkg would fail and give me an error. So originally I had only the 3rd and 4th lines above uncommented/inserted in my config.mk. With that configuration, I could not get the echo command to work, no matter what. Have you uncommented or inserted all of the above 5 lines into your config.mk?
After making sure all of the above 5 lines were in my config.mk, the echo command still didn't work, even if I preceded the command with sudo, or entered a su session. Bash would tell me that there was no such file or directory. I found that if I actually logged out of my normal user, and then logged back into the computer as root, the command would work. If your shell does not give you any feedback (particularly, "no such file or directory"), then the command worked. In order to get the command to run every time the computer boots, I used a systemd service, so that the command is issued as root. For some reason, it doesn't work if you put the command into /etc/profile.
Oh, and it would probably be helpful to mention that for the compat-drivers-patched package from the AUR, the PKGBUILD checks to see what your _selected_drivers variable is before compilation. If you set _selected_drivers=ath9k, your compile times will be much shorter.