I know that AngularJS by default catches all application exceptions and then logs them to the console. That makes the 'Pause on uncaught exceptions' button in Chrome (which I use a lot) useless.
Many times I encounter small javascript errors in my code (like accessing members on undefined variables) and I'm really used to pausing on the exception and inspecting the situation.
The only solution I have by now is either to put a breakpoint on the code which is triggering the error (impractical) or to use the 'Pause on all exceptions' button, but I have to continue on all errors generated by default by jQuery, Angular and other frameworks, and that's also very nasty.
I also tried overwriting the $exceptionHandler service, and put a breakpoint in it, but I don't have access from the call stack in the function that generated the error.
So, is it possible to use the 'Pause on uncaught exceptions' with AngularJS apps?
According to the Angular docs,
https://docs.angularjs.org/api/ng/service/$exceptionHandler
This example will override the normal action of $exceptionHandler, to
make angular exceptions fail hard when they happen, instead of just
logging to the console.
angular.module('exceptionOverride', []).factory('$exceptionHandler', function() {
return function(exception, cause) {
exception.message += ' (caused by "' + cause + '")';
throw exception;
};
});
This will cause them to be handled by the browser dev tools, which will allow pause on caught exceptions, usage of source maps for nice stack traces, etc.
Presumably you don't want this to happen in production, and also don't want to have to add/remove this code continuously during development. We solve this secondary problem by having a 'dev' module which adds to and overrides our production code during development. For example:
In dev.html:
<html ng-app="devApp">
...
In dev.js:
angular.module('devApp', ['mainApp'])
.factory('$exceptionHandler', ...)
The "Skip stepping through sources" is no longer available in Chrome, but - there is a new option - you can right click any script in sources/sources and choose 'Blackbox script'. Then you can turn on 'Pause on Caught Exceptions' without worrying about jQuery and other errors. Personally I use it always on jquery.js and angular.js.
You can enable Skip stepping through sources with particular names in DevTools and set it to something like this:
(jquery|angular|diigolet)
Related
I have some problems to implement Template10 controls in my UWP project.
When I create a PageHeader control into my MainPage.XAML, I can see the control, edit the control and run the application. But unfortunately the application will break until the components initialize.
There´s no error description.
#if DEBUG && !DISABLE_XAML_GENERATED_BREAK_ON_UNHANDLED_EXCEPTION
UnhandledException += (sender, e) =>
{
if (global::System.Diagnostics.Debugger.IsAttached) global::System.Diagnostics.Debugger.Break();
};
endif
}
Visual studio will highlight this line.
What am I doing wrong ?
When I run the Template10 Hamburger template, everything seems to be working fine.
I hope you can help me to understand how template10 is working.
I´ve seen your MVA contents but for me it wasn´t clear how to use template10 in existing projects.
don't forget with this control it sort of needs other things to function correctly. 1 key item is a Frame from which is created at start of the application based on the NavigationServiceFactory if you reference the samples you will see what I am referring to. To drop it in an existing app and expect to run without some modifications, you should expect errors.
I would suggest referencing samples and other things associated. the nuget package can be install to any new project or existing with the right configurations set. theoretically you could set the Frame = {x:null} it should work but I haven't done it or needed to. Or don't set it at all, it's part of the back navigation tracking that the control watches for.
if you hover over the "e" in the method handler inside the ( ), you can look at the errors... e = exception :P, you might have to dig alittle.
Randomly (that's why I ask the question), my application crashes when want to display data into textView.
The only error message I've got in my debug console is :
libc++abi.dylib: terminate_handler unexpectedly threw an exception
I Googled but can't get a clue to find how correct this and how this happens.
I got the same error and a "clean" didn't resolve it.
It was caused by my internet testing flow, I check to see if WiFi is connected but not if that WiFi has an active internet connection that can resolve a supplied URL. It performs a dataWithContentsOfURL: that will ultimately fail. A similar thread made this suggestion to this question here by user Keith that helped me identify the problem -- which was to add breakpoints to C++ exceptions.
To enable -- click your breakpoints view and the very bottom click the '+' to add a breakpoint. Set it up as follows and the stack trance will be more meaningful.
Clean the project.
Check each constraints and remove the corrupted one.
Clean project again, it should works.
This can be caused by an outlet that is no longer existing (might have been renamed or removed).
Here is a tip on how to check outlets:
Select the container view of the suspected outlet, pay attention to "!" marks in the connections inspector.
I got this question ,because I set [self addObserver:self forKeyPath:#"_defaultAgType" options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld context:nil];, but I did not remove it in dealloc. I solved this by [self removeObserver:self forKeyPath:#"_defaultAgType"]; in dealloc function.
Another reason why it could happen is when you have a UI element declared but never added to the screen but still you try to do changes on them.
In my case I had a UIBarButtonItem declared in the code but I never added it to View. When I try to remove it without adding it, I had this issue.
If you renamed/moved your view controller class, make sure you've checked Inherit Module From Target on Identity inspector for your scene on the storyboard
I'm trying to add an event listener to my air application that would prevent the "ActionScript error" window from appearing, so I can handle the error within my application.
I was able to find a little information about this from adobe. I'm just not sure what I should be listening for.
It depends quite a lot on what error is thrown, and why.
Your best bet is to carefully read the ActionScript documentation and add listeners to react to all of the errors that have explicit ErrorEvents (such as IOErrorEvent and SecurityErrorEvent). Those are usually related to network and/or file access, and security issues.
For most other errors, there is the try {} catch() {} finally {} statements. This tutorial might be a good place to start.
And if all else fails, there's UncaughtErrorEvent.
But you should really be using that one as a last resort, not as a magic bullet - the best error handling is a) trying to prevent errors from being thrown in the first place (make sure all variables are properly initialized, test for null, etc.), and b) handling expected runtime errors by catching them explicitly, in order to keep the application running and stable.
You have a couple options. As you know, exception handling is not always possible for certain asynchronous operations.
First off, you need to know what object is responsible for the asynchronous operation that is causing the error. The most sensible approach would be to add the necessary error event handlers to this object.
For instance, a URLLoader performs asynchronous operations; and it's failure can only be handled by adding error event listeners. For example:
var loader: URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE, completeHandler);
loader.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
Another 'catch-all' option is to take advanage of the new UncaughtErrorEvent feature of Flash Player 10.1. For this to work, you need to attach the uncaught error handler to the loader of the main application; this will catch everything! For example:
loader.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, loaderErrorHandler);
private function loaderErrorHandler(e:UncaughtErrorEvent):void {
if(event.error is Error) {
// handle error from embedded SWF
}
// suppress error dialog
e.preventDefault();
}
The last option may not be the best approach as it promotes the swallowing of exceptions instead of addressing and handling the problem properly; nevertheless it can be useful in certain unique circumstances (embedding SWFs).
The window won't appear if you're running the standard version of Flash Player.
It will manifest only as a dialog box on the debugger versions of the
browser plug-ins and stand-alone players, as a message in the output
panel in the authoring player, and as an entry in the log file for
Adobe Flex Builder 3. It will not manifest at all in the release
versions of Flash Player or AIR.
Source : here.
I’m struggling fully understanding when/how exceptions are thrown in JSF 2.0. I’ve looked for a solution longer than I care to admit. Ultimately, the goal I want to achieve is “handle” an unhandled exceptions. When an exception is thrown, I want to be able to capture information of interest about the exception, and email that to the appropriate site administrators. I’m forcing an error by throwing a new FacesException() in the constructor of one of my backing beans. I had this working great in JSF 1.1 using MyFaces implementation. I was able to get this working by wrapping the Default Lifecycle and simply overriding the execute() and render() methods. I followed this awesome post by Hanspeter to get that working:
"http://insights2jsf.wordpress.com/2009/07/20/using-a-custom-lifecycle-implementation-to-handle-exceptions-in-jsf-1-2/#comment-103"
I am now undergoing a site upgrade to JSF 2.0 using Mojarra’s. And things work great still as long as the exception is thrown/caught in the execute() method, however; the moment I enter the render(), the HttpServletResponse.isCommitted() equals true, and the phase is PhaseId RENDER_RESPONSE which of course means I can’t perform a redirect or forward. I don’t understand what has changed between JSF 1.1 and 2.0 in regards to when/how the response is committed. As I indicated, I had this working perfectly in the 1.1 framework.
After much searching I found that JSF 2.0 provides a great option for exception handling via a Custom ExceptionHandler. I followed Ed Burns’ blog, Dealing Gracefully with ViewExpiredException in JSF2:
"http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefully-viewexpiredexception-jsf2"
As Ed indicates there is always the web.xml way by defining the tag and what type of exception/server error code and to what page one wants sent to for the error. This approach works great as long as I’m catching 404 errors. One interesting thing to note about that however, is if I force a 404 error by typing a non-exsitant URL like /myApp/9er the error handler works great, but as soon as I add “.xhtml” extension (i.e. /myApp/9er.xhtml) then the web.xml definition doesn’t handle it.
One thing I noticed Ed was doing that I hadn’t tried was instead of trying to do a HttpServletRespone.sendRedirect(), he is utilizing the Navigationhandler.handleNavigation() to forward the user to the custom error page. Unfortunately, this method didn’t do anything different than what Faclets does with the error by default. Along with that of course, I was unable to do HttpServletResponse.sendRedirect() due to the same problems as mentioned above; response.isCommitted() equals true.
I know this post is getting long so I will make a quick note about trying to use a PhaseListener for the same purposes. I used the following posts as a guide with this route still being unsuccessful:
"http://ovaraksin.blogspot.com/2010/10/global-handling-of-all-unchecked.html" "http://ovaraksin.blogspot.com/2010/10/jsf-ajax-redirect-after-session-timeout.html"
All and all I have the same issues as already mentioned. When this exception is thrown, the response is already in the committed phase, and I’m unable to redirect/forward the user to a standard error page.
I apologize for such a long post, I’m just trying to give as much information as possible to help eliminate ambiguity. Anyone have any ideas/thoughts to a work around, and I’m curious what might be different between JSF 1.1 and 2.0 that would cause the response to be committed as soon as I enter the render() phase of the Lifecycle.
Thanks a ton for any help with this!!!
So this question is actually not just about a custom exception handler (for which JSF 2 has the powerful ExceptionHandlerFactory mechanism), but more about showing the user a custom error page when the response has already been committed.
One universal way to always be able to redirect the user even if the last bit has already been written to the response is using a HttpServletResponse wrapper that buffers headers and content being written to it.
This does have the adverse effect that the user doesn't see the page being build up gradually.
Maybe you can use this technique to only capture the very early response commit that JSF 2.0 seems to do. As soon as render response starts, you emit the headers you buffered till so far and write out the response content directly.
This way you might still be able to redirect the user to a custom error page if the exception occurs before render response.
I have successfully implemented a filter using response wrapper as described above which avoids the response being commited and allows redirection to a custom page even on an exception in the middle of rendering the page.
The response wrapper sets up its own internal PrintWriter on a StringWriter, which is returned by the getWriter method so that the faces output is buffered. In the happy path, the filter subsequently writes the internal StringWriter contents to the actual response. On an exception, the filter redirects to an error jsp which writes to the (as yet uncommitted) response.
For me, the key to avoiding the response getting committed was to intercept the flushBuffer() method (from ServletResponse, not HttpServletResponse), and avoid calling super.flushBuffer(). I suspect that depending on circumstances and as noted above, it might also be necessary to also override some of the other methods, eg the ones that set headers.
While I'm developing my MS Access application, I open it with shift click. When an Error occurs, that is not trapped (by ON ERROR ...), a message box pops up informing me about the error. This is a good thing.
When a user open my application, he does't shift click, and an appropriate Start Form opens. However, now untrapped Errors don't show up, the application behaves as if the user clicked the Stop Button on the message box. I don't want this behaviour.
Is there an option / property / variable that provides the same behaviour in the production code (preferably even when the application id converted to an mde) as in development, i.e. show a message box for every untrapped error? Or is it neccessary to trap errors in every single event routine and pop up a message box by program?
It turns out, this is a side effect of setting the AllowSpecialKeys property to False. This can be done programmatically, but I did it in the menu under Tools > StartUp.
Since this property allows the user to open the code editor, it kind of makes sense, but the relationship of the phenomen described to this option was puzzling for me.
Does this mean, that if I want to hide my code, I need to write all those error handlers? Or is there one central place (like a main method in Java) where I can invoke an error handler. Alternatively, could I allow specical keys and just protect the code with a keyword?
You can create your own error handler and add it to all procs, subs and functions. You have this very nice MZ Tools VBA add-on that allows you many thing such as adding line numbers to your code, "preprogramming" your error label, etc.
If you are smart enough, you'll be able to use this add-on to generate a standard "error management" code displaying things such as err.number, err.description, and the undocument erl value, which is the number of the line where the error occured (you must first have your lines numbered before being able to get this value).
EDIT: I just opened this question on a similar subject.
As alluded to, MZ-Tools 3.0 is a great tool to aid in quickly adding error handlers. Also remember that errors which occur in procedures without error handlers "bubble up" to the last-invoked On Error statement. (And if no statement exists you get the little gray debug box.) The net effect of this, is that you can do minimal error handling by simply adding error handlers only to those procedures which are Public (or Friend) or called by event. This will make sure you always have at least 1 "top level" error handler invoked. If you want to add special handling to your private procedures after that feel free. If not, when an error occurs in them they will "bubble up" to the top level error handler.