How do I catch 'Uncaught typeError: Cannot read property 'isModel' of undefined' during App load? - sencha-touch-2

I'm developing ST2 on Chrome which uses localstorage. From time to time, it appears that the storage schema gets corrupted. When this happens, my app fails during load with "Uncaught typeError: Cannot read property 'isModel' of undefined". The only way to get my app running is to do localstorage.clear() in the console.
I'm assuming this is an ST2 bug, since the occurrence of the corruption seems unrelated to my code, or what I do in my app.
My main question is how do I catch the exception in such a way that either the app can recover, or the user is alerted as to what is going on? Right now, the app simply fails to load. I've tried wrapping the Ext.application() in app.js, but that is executing correctly. My launch function is not being reached.

There must be some weird thing going on with your app. Probably you have found the reason meanwhile and recognised the failing bit is somewhere in your app. Anyway if you are experiencing anything like this then probably the best bet is to catch the error event and do your error handling there. I.e.
window.addEventListener("error", function(errorEvent) {
//
// Add your error handling here
//
// if returns true, the error is suppressed and not thrown
return false;
});

Related

How to implement global error handling in Vue

I want to have global error handling in Vue.JS, like the error handling system in Angular 2+. I have tried so much but I could not find a good approach to implement this handling.
Imagine you have many service methods and that these methods should run one after the other (I mean inside each other) so writing then and catch method inside the prevoius service is so ugly and unclean and now I'm looking for clean way to implement such way. I hope you understand what I mean.
As #Badgy mentioned you can install a Vue error handler to catch errors Vue encounters. This can be done as follows:
Vue.config.errorHandler = function (err, vm, info) {
// handle error
// `info` is a Vue-specific error info, e.g. which lifecycle hook
// the error was found in. Only available in 2.2.0+
}
The above code can be located anywhere you like in your javascript. I locate the code just before I create my vue instance. i.e before my var app = new Vue({...}); code. Because it's a global vue error handler it will handle errors from all instances of vue as well as vue components. I find that in practice it mostly catches errors that occur in the vue render methods.
You can read more about it in the official docs here: https://v2.vuejs.org/v2/api/#errorHandler
For more general (non vue related) javascript errors you still need a global error handler like so:
window.onerror = function (msg, url, line, col, error) {
//code to handle or report error goes here
}
Again, this code can be placed anywhere javascript is allowed but typically you will want to place it to run early in your javascript stack. You can read more about this here: https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror
And finally, to catch a "Promise rejection" (i.e. an exception throw from a Promise function) we need to listen for unhandledrejection events since a Promise rejection is not caught by the window.onerror mechanism (thanks to #Blauhirn for the tip). In some browsers (Chrome and Edge currently) Promise rejections can be caught with the following approach:
window.addEventListener('unhandledrejection', function(event) {
//handle error here
//event.promise contains the promise object
//event.reason contains the reason for the rejection
});
For more info see this StackOverflow question: Catch all unhandled javascript promise rejections
I hope i understood your Question Right, but this could be what you are Looking for.
errorCaptured
Type: (err: Error, vm: Component, info: string) => ?boolean
Details: Called when an error from any descendent component is
captured. The hook receives three arguments: the error, the component
instance that triggered the error, and a string containing information
on where the error was captured. The hook can return false to stop the
error from propagating further.
Here is more in-Depth Info About it.
Be careful its Vue 2.5.0+

Persistent React-Native error that goes away with Remote Debugging enabled

I'm building a React-Native app and whenever I run it on my Android emulator, I get this error:
Objects are not valid as a React child (found: object with keys
{$$typeof, type, key, ref, props, _owner, _store}). If you meant to
render a collection of children, use an array instead.
throwOnInvalidObjectType
D:\rn\manager\node_modules\react-native\Libraries\Renderer\ReactNativeRenderer-dev.js:7436:6
Because this error means nothing to me, I decide to enable "Debug JS Remotely" in Chrome to see if I can get an error I understand. But with Debug Remotely enabled, the error goes away.
If I build the project and install the app on a real device, the errors come back.
But I feel like I'm stuck in a catch-22 because if I try to debug, I get no errors, and if I turn off debugging, I get errors.
Is there anyway to get around this?
Thanks!
The error mentions you use an object in your render() method where you shouldn't. Since you did not post any code, here is what you could do:
Keep removing elements from your render() method until you no longer get the error. Once it is gone, start placing code back until you hit the error again. The code causing the error will be or return an object, possibly a typo causing an object to be returned instead of a string for instance.
TL;DR: Stopped using firebase and used react-native-firebase instead
The problem for me wasn't the render method in any of my components or classes. I realized after trying the answer above, I basically removed all my files, and was left with one file. I changed the render method to display text inside one view, but I still got the error.
Then I started removing the modules I was importing inside that file one by one and found that it was the firebase module uninstalled firebase and installed react-native-firebase.

WinJS app with an uncatchable crash

I have random crashes in my WinJS application when navigating between pages.
The problem is that these crashes never occurs when the app is attached to the Visual Studio debugger; so I can't find where they come from.
I use the WinJS.Application.onerror event to prevent crashes, and log what happens, but as this works well when I try with a random exception, my "uncatchable" crashes doesn't seem to fire this event (I don't have anything logged).
Do you have any idea of what could cause these crashes, or any solution to find more informations ?
Sometimes errors can't fire the WinJS.Application.onerror for several reasons (in my app, the problem was in an iframe, in a page not using winjs).
When it happens, errors can be found in the event log, under "administrative events"
Found this on this link :
http://www.davepaquette.com/archive/2012/09/15/windows-8-store-app-crash-logs.aspx
Jason gives a good solution to this problem in this video (start at time 14:48). In his example, the app was crashing if you had a callback and navigated to a different page before the callback completed. Could this be the case for your app? Any more details on what is going on when you navigate?
For others (since it seems you already know about this!):
To be able to debug easier, use the WinJS.Application.OnError event. Wire up an event handler that dumps out information about the problem before the app crashes.
WinJS.Application.onerror = function (info) {
var err = {
errorMessage: info.detail.errorMessage,
errorUrl: info.detail.errorUrl,
errorLine: info.detail.errorLine,
errorCharacter: info.detail.errorCharacter,
};
Windows.Storage.ApplicationData.current.localFolder
.createFileAsync("crash.txt", Windows.Storage.CreationCollisionOption.openIfExists)
.then(function (file) {
Windows.Storage.FileIO.appendLinesAsync(file, [JSON.stringify(err)]);
});
};
The final stop for exceptions in JavaScript is actually window.onerror; not every exception will get thrown through WinJS.Application.onerror. Try hooking window.onerror directly.

CreateFileAsync in SuspensionManager throws indecipherable exception

I created a new Windows Store app project using the Grid App (XAML) template. I ran the project (in debug mode) without changing a single line of code. While it was running, I switched back to Visual Studio and clicked the Suspend button in the toolbar.
At this point, the app threw a SuspensionManagerException. The exception’s details weren’t too helpful. The message is SuspensionManager failed. It has the (so far) unhelpful HResult -2146233088. It also has an InnerException that’s just as unhelpful. Its message is Error HRESULT E_FAIL has been returned from a call to a COM component. and its HResult, which is -2147467259, is even worse than the outer exception’s HResult.
The line of code that throws the exception is in the SuspensionManager, which, again, is part of the project template. Here’s the line:
StorageFile file = await ApplicationData.Current.LocalFolder.CreateFileAsync(sessionStateFilename, CreationCollisionOption.ReplaceExisting);
The part that triggers the exception is LocalFolder.CreateFileAsync(…). The MSDN documentation for the CreateFileAsync method has a “Remarks” section that reads: If you try to create a file in a virtual folder like a library or a file group, this method may fail.
That’s it. There’s no explanation of why it may fail, or a description of the conditions under which it may fail, or what you can do about it.
As it happens, even when it fails, the file is actually created. The file in question is called _sessionState.xml and is located at C:\Users\<username>\AppData\Local\Packages\<package_id>\LocalState. If I delete the file and re-suspend the app, the exception is throw again and the file is recreated.
I've searched high and low and haven't found anything conclusive. The CreateFileAsync method is a projection, so I can't easily disassemble it or figure out why it "may fail".
Does anybody have any idea what could be causing this problem, or how to go about debugging or solving it?
The first thing to check is that Frame.Navigate should only take primitives as its parameter argument.
Also, make sure you are calling GetDeferral in your async event handler.

NSURLErrorDomain -999 breaks Flash

I have a WebView which works great except in one instance. When it loads a page with a SWF that loads another SWF, the load delegate gets "The operation couldn’t be completed. (NSURLErrorDomain error -999.)"
From what I gather, this error happens when a second request is made before the first has completed (1, 2, 3, 4). I am not expressly doing so, but the SWF is indeed making another request.
Ignoring the error is not a solution--I'm essentially ignoring it as is, and the entire page loads fine except for the Flash content. What can I do to make Flash work?
I'm not sure if not implementing the delegate call is the same as ignoring it; WebKit might be trying to handle the error under the hood and causing problems.
In my WebKit/Flash application, I have this in my WebFrameLoadDelegate:
- (void) webView:(WebView*)sender
didFailProvisionalLoadWithError:(NSError*)error
forFrame:(WebFrame*)frame
{
// If the user clicks a link while something is loading this error will
// be reported. It can be safely ignored (NSURLErrorCancelled -999)
if ([error code] == NSURLErrorCancelled) return;
// Real error handling here...
}
And everything works fine. If I take this out I start getting weird failures and even crashes when Flash content is displayed.