"An exception has been encountered. This may be caused by an extension. C:\Users\mine\AppData\Roaming\Microsoft\VisualStudio\15.0_5f2147be\ActivityLog.xml"
This dialog box is shown when I am trying to build an API in Visual studio 2017. I have disabled all the extensions but still this dialog box is appearing. How I can solve this?
Please learning debugging in order to identify the problems and use try catch of get details of the exception. Then you are able to identify the problems yourself.
Please read this article to learn more about debugging
http://www.c-sharpcorner.com/article/debugging-with-visual-studio/
In order to catch exceptions use the following code block.
try
{
//your code
}
catch(Exception ex)
{
throw ex;
}
Related
My MVC application uses error pages, configured in the web.config file. All errors display a single web page, regardless of the type of error. This works fine.
The problem I have though, is the exception isn't thrown in the web project, but in my BLL project. So, consider this
//My Web.Ui
public ActionResult Thing()
{
Bll.Statics.DoThis();
return View();
}
and my BLL is
public static void DoThis()
{
throw new Exception("Kaboom");
}
The problem is, when the error occurs here, I don't see my 404 page, I get a standard 'browser' error page explaining something when wrong.
Do I simply just need to wrap all calls in Try Catch from my Controllers so I can throw (re-throw) the exception from the controller itself?
Yes, wrap all your calls in a try-catch block. On the other hand think about the exceptions that you might be catching. Do you want to catch Exception or you want to give different information, like in case of SqlException when you don't have connection to the database, etc. If all you want is to show your custom 404, then you might go with a generic option.
I don't even know what to call this, but here's the situation - I use Visual Studio 2013 to create a Windows Forms Project. At some point, the debugger started throwing out this error:
An unhandled exception of type 'System.Reflection.TargetInvocationException' occurred in mscorlib.dll
Additional information: Exception has been thrown by the target of an invocation.
However, I happened to notice that when I run the program without debugging, and the error occurs, it gives me:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
It's not a complicated program, I'm not doing anything like multithreading or delegating yet. No matter what I try, it only gives the first error. I've gotten it when I was try to delete a file that didn't exist, when the index was out of bounds, when a control threw an error. All these errors just quoted the first one in debug mode, but the normal errors out of debug mode.
I just threw the code in another project and it works fine. Maybe it's a option in the debugging menu, but I've tried everything I could imagine. I also tried updating to VS2013 Update 4 and it still does it. Help?
An unhandled exception of type 'System.Reflection.TargetInvocationException' occurred in mscorlib.dll
Additional information: Exception has been thrown by the target of an invocation.
A TargetInvocationException is a wrapper around the actual exception.
"The client application's event-handler delegate should check the Error property; otherwise, the property will raise a TargetInvocationException"
Try returning a try catch and get the ex.InnerException
and see why it is giving this error
System.IndexOutOfRangeException: Index was outside the bounds of the array.
try this as well
try {
//here you read the arguments and pass to a variable
}
catch(System.IndexOutOfRangeException) {
//other codepart
}
Hope this helps
When rendering starts, my controller code is already ran. If there is an error in the view script, it usually results in an empty or half-rendered page. I have checked the code and there is no event to subscribe to, PHPRenderer just re-throws the exception:
try {
ob_start();
include $this->__file;
$this->__content = ob_get_clean();
} catch (\Exception $ex) {
ob_end_clean();
throw $ex;
}
For controllers, there is a 'dispatch.error' event, but that does not work here. Is there any way to catch these rendering errors and log/display the error properly?
There is a 'render.error' event that you can attach listeners to. See http://framework.zend.com/manual/2.1/en/modules/zend.mvc.mvc-event.html .
There is no such thing in the 2.0.x branch.
For the 2.1.x branch look the other answer.
Anyway, there is no such an event you could use. But I don't think you need it. You should not be having errors in your view, since view is for displaying things only, not for business logic. So I would say you need to fix your view instead of finding a way to catch those exceptions.
As for error logs, you could check apache logs.
I am writing an editor based on xtext. (v 2.2.1)(Eclipse Indigo)
I have a class that extends DefaultLinkingServic and overrides the method:
public List getLinkedObjects(EObject context, EReference ref, INode node) throws IllegalNodeException.
The method throws IllegalNodeException when an object cannot be resolved.
When the exception is thrown (and it should be thrown) the error is not only written to the error log, but it causes a popup window to appear with the error:
An internal error occurred during: "Xtext validation".
org.eclipse.xtext.linking.impl.IllegalNodeException: Action App.f is not applicable for the specified arguments.
This is very problematic especiallyif the file has multiple errors which makes it impossible to edit anything in the editor, since the popup repeatedly appears on screen.
This problem is consistent in several IDE's but in others is not reproducible.
Any help would be greatly appreciated.
You are stumbling accross this bug which was already fixed for 2.3 (due June).
As a workaround, you may want to bind a custom implementation of the LazyLinkingResource and catch the IllegalNodeException in #getEObject. Alternativley you could return an empty list from your custom LinkingService instead of raising an IllegalNodeException.
This may be a debugger issue, but here goes:
I have this piece of code:
Private Function Connect() As Boolean
Try
sessionBegun = False
connectionOpen = False
rp = New RequestProcessor2()
rp.OpenConnection2("","EZSystem", QBXMLRPConnectionType.localQBD)
connectionOpen = True
ticket = rp.BeginSession("", QBFileMode.qbFileOpenDoNotCare)
sessionBegun = True
Return True
Catch e As COMException
exceptionHandler.HandleConnectionException(e)
**Throw New QuickBooksConnectionException(e.Message)**
End Try
End Function
My intention is to 'convert' the low level exception into something more meaningful, so I throw an exception of my own creation. I want this to bubble up to a place where I can handle it.
However what is happening is my debugger breaks and tells me that an exception of type "QuickBooksConnectionException" was thrown.
I know that, I just threw it, why are you catching it?
From what I've read, this ought to work, and there doesn't appear to be an analogous Java throws keyword, so perhaps it is my debugger.
I am using SharpDevelop.
Thanks,
Dane
As written, your code throws an unhandled exception, which is always going to cause the debugger to balk. You just have to catch the QuickBooksConnectionException in the code that invokes this method. (And you're right, there's no equivalent in C# to the throws Java keyword.)
You can change the setting for when the debugger breaks for exceptions.
See here.
This is just the debugger doing its job. It usually catches any unhandled exceptions. I think your code is working fine, it's the debugger that's maybe confusing you.
Here's an experiment to show what's going on. Remove your Try-Catch block completely. Run the code & cause a COMException. The debugger will "catch" it, because it's unhandled, and highlight the line that throws it.
An exception bubbles up the call stack looking for an enclosing Try block. If there's no enclosing Try block, then the runtime deals with it. Which means that if you are running under a debugger, the debugger will rewind the call stack back so it can show you the original line that threw the exception. To help you debug why the exception happened. Try running from a standalone EXE or website with no debugger. It will terminate with a standard error dialogue.
Here are the rules that determine whether the debugger breaks on an exception.