Il presente articolo è stato tradotto automaticamente.
WinJS in Windows 8.1
Creazione di applicazioni Windows Store più efficienti con JavaScript: gestione degli errori
Che ci crediate o no, a volte gli sviluppatori di app e scrivere codice che non funziona. O il codice funziona, ma è terribilmente inefficiente e maiali memoria. Peggio ancora, codice inefficiente provoca un povero UX, facendo impazzire gli utenti e costringendo a disinstallare l'app e lasciare recensioni negative.
Ho intenzione di esplorare i problemi comuni, prestazioni ed efficienza, che potrebbero verificarsi durante la creazione di applicazioni Windows Store con JavaScript. In questo articolo, dare un'occhiata alle procedure consigliate per la gestione degli errori, utilizzando la libreria Windows per JavaScript (WinJS). In un prossimo articolo, mi occuperò tecniche per fare il lavoro senza bloccare il thread dell'interfaccia utente, in particolare utilizzando Web lavoratori o la nuova API WinJS.Utilities.Scheduler in WinJS 2.0, come trovato in Windows 8.1. Inoltre presento il nuovo modello del ciclo di vita prevedibile-oggetto in WinJS 2.0, concentrandosi particolarmente su quando e come smaltire i controlli.
Per ogni area disciplinare, mi concentro su tre cose:
- Errori o inefficienze che potrebbero sorgere in un'applicazione Windows Store costruita utilizzando JavaScript.
- Strumenti diagnostici per trovare quegli errori e inefficienze.
- WinJS APIs, caratteristiche e migliori pratiche che possono migliorare i problemi specifici.
Fornisco qualche codice volutamente bacato, ma, tranquilli, indicare nel codice che qualcosa è o non è supposto per lavorare.
Io uso Visual Studio 2013, Windows 8.1 e WinJS 2.0 per queste dimostrazioni. Molti degli strumenti diagnostici che uso sono forniti in Visual Studio 2013. Se non hai scaricato le versioni più recenti degli strumenti, è possibile ottenere da Windows Dev Center (bit.ly/K8nkk1). Nuovi strumenti diagnostici vengono rilasciati attraverso gli aggiornamenti Visual Studio , quindi assicuratevi di controllare periodicamente gli aggiornamenti.
Presumo significativa familiarità con la creazione di applicazioni Windows Store utilizzando JavaScript. Se siete relativamente nuovo per la piattaforma, vi suggerisco di inizio con l'esempio "Hello World" di base (bit.ly/vVbVHC) o, per più di una sfida, il campione di Hilo per JavaScript (bit.ly/SgI0AA).
Impostazione di esempio
In primo luogo, creare un nuovo progetto in Visual Studio 2013 utilizzando il modello di navigazione App che fornisce una buona partenza punto per un app di base multipagina. Aggiungo anche un controllo della barra di navigazione (bit.ly/14vfvih) alla pagina default. html nella directory principale della soluzione, sostituendo AppBar codice la dima fornita. Perché voglio dimostrare più concetti, strumenti di diagnostica e tecniche di programmazione, aggiungerò una nuova pagina per le app per ogni dimostrazione. Questo rende molto più facile per me navigare tra tutti i casi di test.
Il codice HTML completo per la barra di navigazione è mostrato Figura 1. Copia e incolla questo codice nella vostra soluzione se stai seguendo insieme con l'esempio.
Figura 1 il controllo barra di navigazione
<!-- The global navigation bar for the app.
-->
<div id="navBar" data-win-control="WinJS.UI.NavBar">
<div id="navContainer"
data-win-control="WinJS.UI.NavBarContainer">
<div id="homeNav"
data-win-control="WinJS.UI.NavBarCommand"
data-win-options="{
location: '/pages/home/home.html',
icon: 'home',
label: 'Home page'
}">
</div>
<div id="handlingErrors"
data-win-control="WinJS.UI.NavBarCommand"
data-win-options="{
location: '/pages/handlingErrors/handlingErrors.html',
icon: 'help',
label: 'Handling errors'
}">
</div>
<div id="chainedAsync"
data-win-control="WinJS.UI.NavBarCommand"
data-win-options="{
location: '/pages/chainedAsync/chainedAsync.html',
icon: 'link',
label: 'Chained asynchronous calls'
}">
</div>
</div>
</div>
Per ulteriori informazioni sulla creazione di una barra di navigazione, verificare alcune delle colonne moderne applicazioni di Rachel Appel, come quella in msdn.microsoft.com/magazine/dn342878.
Si può eseguire questo progetto con la barra di navigazione, tranne che cliccando i pulsanti di navigazione verrà generata un'eccezione in Navigator.Più avanti in questo articolo, illustrerò come gestire gli errori che vengono in su in Navigator.Per ora, ricordate l'app inizia sempre a casa apagina e dovete fare clic destro il app per far apparire la barra di navigazione.
Gestione degli errori
Ovviamente, il modo migliore per evitare errori è quello di rilasciare le apps che non generano errori.In un mondo perfetto, ogni sviluppatore scrivere codice perfetto che mai si blocca e non genera un'eccezione.Quel mondo perfetto non esiste.
Per quanto riguarda gli utenti preferiscono le app che sono completamente privo di errori, essi sono eccezionalmente bravi a trovare modi nuovi e creativi per rompere apps — modi che mai sognato.Di conseguenza, è necessario incorporare robusto errore gestione nelle tue applicazioni.
Errori nell'app di Windows Store con JavaScript e HTML agiscono come errori in normali pagine Web.Quando si verifica un errore in un oggetto Document Object Model (DOM) che permette la gestione degli errori (per esempio, lo script < >, < style > o < img > elementi), viene generato l'evento onerror per quell'elemento.Errori nello stack di chiamate JavaScript, l'errore viaggia lungo la catena di chiamate fino a quando catturato (in un blocco try/catch, per esempio) o fino a raggiungere l'oggetto window, generando l'evento OnError.
WinJS fornisce diversi strati di opportunità di gestione degli errori di codice oltre a quanto già previsto alle normali pagine Web dalla piattaforma Web Microsoft.A un livello fondamentale, qualsiasi errore non intrappolato in un blocco try/catch o il gestore onError applicato a un WinJS oggetto (in una chiamata ai metodi allora o fatto, per esempio) genera l'evento WinJS.Application.onerror.Che potrai esaminare brevemente.
In pratica, si può ascoltare per errori ad altri livelli oltre Application.onerror.Con WinJS e i modelli forniti da Visual Studio, è possibile anche gestire errori a livello di controllo della pagina e a livello di navigazione.Mentre l'app è spostarsi e caricamento di una pagina, viene generato un errore, l'errore attiva la gestione dell'errore a livello di navigazione, quindi la gestione dell'errore a livello di pagina e infine la gestione dell'errore a livello di applicazione.È possibile annullare l'errore a livello di navigazione, ma i gestori di eventi applicati per il gestore di errore pagina ancora verranno generati.
In questo articolo, mi prenderò uno sguardo a ogni strato di errore di manipolazione, cominciando con le più importanti: l'evento Application.onerror.
Gestione degli errori a livello di applicazione
WinJS fornisce l'evento WinJS.Application.onerror (bit.ly/1cOctjC), linea di base dell'app di difesa contro gli errori.Raccoglie tutti gli errori catturati da OnError." Cattura anche promesse che errore fuori ed eventuali errori che si verificano nel processo di gestione di eventi modello app.Anche se nella tua app, è possibile applicare un gestore eventi per l'evento OnError, sei meglio usare solo Application.onerror per una singola coda di eventi da monitorare.
Una volta che il gestore Application.onerror rileva un errore, è necessario decidere come affrontarla.Ci sono diverse opzioni:
- Per errori di blocchi critici, avvisare l'utente con una finestra di dialogo del messaggio.Un errore critico è quella che colpisce il funzionamento continuato dell'app e potrebbe richiedere l'input dell'utente per procedere.
- Informativo e non bloccante errori (ad esempio un errore di sincronizzazione o di ottenere dati online), avvisare l'utente con un riquadro a comparsa o un messaggio in linea.
- Per errori che non incidono la UX, ingoiare in silenzio l'errore.
- Nella maggior parte dei casi, l'errore di scrittura per un tracelog (soprattutto quello che è collegato ad un motore di analisi) così si può acquisire la telemetria del cliente.Per analytics disponibile SDK, visitare la directory di servizi di Windows al services.windowsstore.com e fare clic su Analytics (sotto "dal tipo di servizio") nell'elenco a sinistra.
In questo esempio, attaccherò con le finestre di dialogo di messaggio.Apro js (/ js/default.js) e aggiungere il codice riportato Figura 2 all'interno della funzione anonima principale, sotto il gestore per l'evento app.oncheckpoint.
Figura 2 l'aggiunta di una finestra di dialogo del messaggio
app.onerror = function (err) {
var message = err.detail.errorMessage ||
(err.detail.exception && err.detail.exception.message) ||
"Indeterminate error";
if (Windows.UI.Popups.MessageDialog) {
var messageDialog =
new Windows.UI.Popups.MessageDialog(
message,
"Something bad happened ...");
messageDialog.showAsync();
return true;
}
}
In questo esempio, il gestore di eventi di errore mostrato un messaggio che dice che l'utente si è verificato un errore e che cosa è l'errore. Il gestore eventi restituisce true per mantenere la finestra di dialogo di messaggio aperta fino a quando l'utente lo chiude. (Restituendo true informa anche il processo di WWAHost.exe che l'errore è stato gestito e può continuare.)
Ora creeremo alcuni errori per questo codice da gestire. Potrai creare un errore personalizzato, generare l'errore e poi prenderlo nel gestore eventi. In questo primo esempio, aggiungere una nuova cartella denominata movimentazioneerrori nella cartella pagine. Nella cartella, aggiungere un nuovo controllo Page cliccando col tasto destro il progetto in Esplora soluzioni e scegliendo Add | Nuovo elemento. Quando aggiungo il controllo Page handlingErrors al mio progetto, Visual Studio fornisce tre file nella cartella handlingErrors (handlingErrors/pagine /): handlingErrors.html, gestioneErrors.js e handlingErrors.css.
Io aprire handlingErrors.html e aggiungere questo semplice markup all'interno della sezione < > etichetta del corpo:
<!-- When clicked, this button raises a custom error.
-->
<button id="throwError">Throw an error!</button>
Successivamente, aprire handlingErrors.js e aggiungere un gestore eventi per il pulsante nel metodo pronto dell'oggetto PageControl, come mostrato Figura 3. Ho fornito l'intera definizione di PageControl in handlingErrors.js per il contesto.
Figura 3 definizione di handlingErrors PageControl
// For an introduction to the Page Control template, see the following documentation:
// https://go.microsoft.com/fwlink/?LinkId=232511
(function () {
"use strict";
WinJS.UI.Pages.define("/pages/handlingErrors/handlingErrors.html", {
ready: function (element, options) {
// ERROR: This code raises a custom error.
throwError.addEventListener("click", function () {
var newError = new WinJS.ErrorFromName("Custom error",
"I'm an error!");
throw newError;
});
},
unload: function () {
// Respond to navigations away from this page.
},
updateLayout: function (element) {
// Respond to changes in layout.
}
});
})();
Ora si preme F5 per eseguire l'esempio, passare alla gestioneErrori pagina e clicca sul pulsante "Genera un errore!". (Se stai seguendo, vedrete una finestra di dialogo da Visual Studio , informandovi che è stato generato un errore. Fare clic su continua per mantenere il campione in esecuzione.) Una finestra di dialogo di messaggio si apre poi con l'errore, come illustrato nel Figura 4.
.png)
Figura 4 l'errore personalizzato visualizzato in una finestra di dialogo del messaggio
Errori personalizzati
L'evento Application.onerror ha alcune aspettative circa gli errori che lo gestisce. Il modo migliore per creare un errore personalizzato è utilizzare l'oggetto WinJS.ErrorFromName (bit.ly/1gDESJC). L'oggetto creato espone un'interfaccia standard per gestori di errori da analizzare.
Per creare il proprio errore personalizzati senza utilizzare l'oggetto ErrorFromName, è necessario implementare un metodo toString che restituisce il messaggio dell'errore.
In caso contrario, quando viene generato l'errore personalizzato, sia il debugger Visual Studio e la finestra di dialogo di messaggio Visualizza "[oggetto]." Ognuno di essi chiama il metodo toString dell'oggetto, ma poiché nessun tale metodo è definito nell'oggetto immediato, passa attraverso la catena di ereditarietà di prototipo per una definizione di toString. Quando raggiunge il tipo di oggetto primitivo che dispongono di un metodo toString, chiama quel metodo (che visualizza solo informazioni sull'oggetto).
Gestione degli errori a livello di pagina
L'oggetto PageControl in WinJS fornisce un ulteriore livello di gestione degli errori per un app. WinJS chiamerà il metodo IPageControlMembers.error quando si verifica un errore durante il caricamento della pagina. Dopo che ha caricato la pagina, tuttavia, gli errori di metodo IPageControlMembers.error vengono prelevati dal gestore eventi Application.onerror, ignorando il metodo della pagina errore.
Aggiungerò un metodo di errore per il PageControl che rappresenta la pagina handleErrors. Il metodo errore scrive nella console JavaScript in Visual Studio utilizzando WinJS.log. La funzionalità di registrazione deve essere iniziato in primo luogo, quindi ho bisogno di chiamare WinJS.Utilities.startLog prima di tentare di utilizzare tale metodo. Si noti inoltre che verifica l'esistenza del membro WinJS.log prima chiamo in realtà.
Il codice completo per handleErrors.js (/ pages/handleErrors/handleErrors.js) è mostrato Figura 5.
Figura 5 il completo handleErrors.js
(function () {
"use strict";
WinJS.UI.Pages.define("/pages/handlingErrors/handlingErrors.html", {
ready: function (element, options) {
// ERROR: This code raises a custom error.
throwError.addEventListener("click", function () {
var newError = {
message: "I'm an error!",
toString: function () {
return this.message;
}
};
throw newError;
})
},
error: function (err) {
WinJS.Utilities.startLog({ type: "pageError", tags: "Page" });
WinJS.log && WinJS.log(err.message, "Page", "pageError");
},
unload: function () {
// TODO: Respond to navigations away from this page.
},
updateLayout: function (element) {
// TODO: Respond to changes in layout.
}
});
})();
WinJS.log
La chiamata a WinJS.Utilities.startLog mostrato Figura 5 avvia la funzione di supporto WinJS.log, che scrive l'output nella console JavaScript di default. Mentre questo aiuta notevolmente durante la fase di progettazione per il debug, non consente di catturare i dati di errore dopo che gli utenti hanno installato l'app.
Per le applicazioni pronte essere pubblicato e distribuito, è consigliabile creare un'implementazione personalizzata di WinJS.log che chiama in un motore di analisi. Questo consente di raccogliere dati di telemetria sulle prestazioni dell'applicazione in modo è possibile risolvere bug imprevisti in future versioni dell'app. Basta assicurarsi che i clienti siano consapevoli della raccolta dati e che chiaramente elencare quali dati ottiene raccolti dal motore di Google analytics nell'informativa sulla privacy dell'app.
Nota che quando si sovrascrive WinJS.log in questo modo, la WinJS.log funzione cattura tutti output che altrimenti passerebbero nella console JavaScript, tra cui cose come aggiornamenti di stato dall'utilità di pianificazione. Ecco perché è necessario passare un nome significativo e digitare il valore nella chiamata a WinJS.Utilities.startLog così è possibile filtrare eventuali errori che non volete.
Ora cercherò esecuzione dell'esempio e cliccando "generano un errore!" ancora una volta. Il risultato è lo stesso comportamento esatto come prima: Visual Studio preleva l'errore e quindi viene generato l'evento Application.onerror. La console JavaScript non Mostra i messaggi relativi all'errore, perché l'errore è stato generato dopo la pagina caricata. Così, l'errore è stato raccolto solo dal gestore eventi Application.onerror.
Allora perché utilizzare la gestione degli errori di PageControl? Beh, è particolarmente utile per l'individuazione e la diagnosi di errori nei controlli WinJS creati in modo dichiarativo nel codice HTML. Per esempio, io aggiungo il seguente tag HTML all'interno della sezione < > Tag di handleErrors.html (/ pages/handleErrors/handleErrors.html), sotto il pulsante:
<!-- ERROR: AppBarCommands must be button elements by default
unless specified otherwise by the 'type' property.
-->
<div data-win-control="WinJS.UI.AppBarCommand"></div>
Ora si preme F5 per eseguire l'esempio e passare alla pagina handleErrors. Ancora una volta, la finestra di messaggio viene visualizzata finché non respinto. Tuttavia, nella console JavaScript (sarà necessario tornare al desktop per controllare questo) viene visualizzato il messaggio seguente:
pageError: Page: Invalid argument: For a button, toggle, or flyout command, the element must be null or a button element
Si noti che la gestione di app-livello errore apparso anche se ho gestito l'errore nel PageControl (che ha registrato l'errore). Allora come posso intercettare un errore su una pagina senza avere esso bolla fino all'applicazione?
Il modo migliore per intercettare un errore a livello di pagina è quello di aggiungere al codice di navigazione di gestione degli errori. Illustrerò quello successivo.
Gestione degli errori a livello di navigazione
Quando ho eseguito il test precedente dove la app.onerrore evento gestore gestito l'errore a livello di pagina, l'app sembrava rimanere sulla homepage. Ancora, per qualche motivo, è apparso un controllo pulsante Back. Quando ho cliccato il pulsante indietro, mi ha portato a una pagina di handlingErrors.html (disabili).
Questo è perché la navigazione codice in Navigator (/ js/navigator.js), che viene fornito nel modello di progetto applicazione di navigazione, ancora tentativi di passare alla pagina anche se la pagina è svanito. Inoltre, consente di spostarsi indietro homepage e aggiunge la pagina soggetta alla cronologia di navigazione. Ecco perché vedo il pulsante indietro sulla homepage, dopo che ho tentato di passare a handlingErrors.html.
Per annullare l'errore in Navigator, sostituire il PageControlNavigator._navigating funzione con il codice in Figura 6. Si vede che la funzione di navigazione contiene una chiamata a WinJS, che restituisce un oggetto di promessa. Il metodo render tenta di creare un nuovo oggetto PageControl da URI passato ad essa e inserirla in un elemento host. Perché il PageControl risultante contiene un errore, gli errori restituiti promessa fuori. Per intercettare l'errore generato durante la navigazione, aggiungere un gestore di errore per il parametro onError del metodo poi esposto da tale oggetto di promessa. Ciò intrappola efficacemente l'errore, impedendole di generazione dell'evento Application.onerror.
Figura 6 la funzione PageControlNavigator._navigating in Navigator
// Other PageControlNavigator code ...
// Responds to navigation by adding new pages to the DOM.
_navigating: function (args) {
var newElement = this._createPageElement();
this._element.appendChild(newElement);
this._lastNavigationPromise.cancel();
var that = this;
this._lastNavigationPromise = WinJS.Promise.as().then(function () {
return WinJS.UI.Pages.render(args.detail.location, newElement,
args.detail.state);
}).then(function parentElement(control) {
var oldElement = that.pageElement;
// Cleanup and remove previous element
if (oldElement.winControl) {
if (oldElement.winControl.unload) {
oldElement.winControl.unload();
}
oldElement.winControl.dispose();
}
oldElement.parentNode.removeChild(oldElement);
oldElement.innerText = "";
},
// Display any errors raised by a page control,
// clear the backstack, and cancel the error.
function (err) {
var messageDialog =
new Windows.UI.Popups.MessageDialog(
err.message,
"Sorry, can't navigate to that page.");
messageDialog.showAsync()
nav.history.backStack.pop();
return true;
});
args.detail.setPromise(this._lastNavigationPromise);
},
// Other PageControlNavigator code ...
Promesse in WinJS
Creazione di promesse e promesse di concatenamento — e le migliori pratiche per farlo — sono state trattate in altri luoghi, quindi salterò quella discussione in questo articolo. Se avete bisogno di ulteriori informazioni, controllare il post sul blog di Kraig Brockschmidt presso bit.ly/1cgMAnu o Appendice A nel suo e-book gratuito, "Programmazione Windows Store Apps con HTML, CSS e JavaScript, seconda edizione" (bit.ly/1dZwW1k).
Si noti che è interamente corretto modificare Navigator. Anche se esso è fornito dal modello di progetto Visual Studio e fa parte del codice dell'applicazione può essere modificata tuttavia è necessario.
Nella funzione _navigating, ho aggiunto un gestore errori per la chiamata finale promise.then. Il gestore di errore indica una finestra di dialogo di messaggio — come con la gestione del livello di applicazione errore — e quindi Annulla l'errore restituendo il valore true. Inoltre rimuove la pagina della storia della navigazione.
Quando eseguire il campione nuovamente e passare a handlingErrors.html, vedo la finestra di dialogo del messaggio che mi informa che non è riuscito il tentativo di navigazione. Non appare la finestra di dialogo di messaggio dalla gestione dell'errore a livello di applicazione.
Rintracciare errori in catene asincrone
Quando si creano applicazioni in JavaScript, ho bisogno frequentemente di seguire un'attività asincrona con un'altra, che mi rivolgo con la creazione di catene di promessa. Promesse incatenati continuerà muovendo attraverso le attività, anche se una delle promesse della catena restituisce un errore. Una best practice è alla fine sempre una catena di promesse con una chiamata al metodo fatto. La funzione di fatta genera errori che sarebbe stato preso nel gestore dell'errore per qualsiasi precedente allora dichiarazioni. Questo significa che non ho bisogno di definire funzioni di errore per ogni promessa in una catena.
Anche così, rintracciare errori può essere difficile in catene molto lunghe una volta sono intrappolati nella chiamata a promise.done. Incatenato promesse possono includere più attività, e uno di loro potrebbe fallire. Ho potuto impostare un punto di interruzione in ogni attività per vedere dove l'errore compare, ma che sarebbe terribilmente richiede tempo.
Qui è dove Visual Studio 2013 viene in soccorso. La finestra di attività (introdotta in Visual Studio 2010) è stata aggiornata per gestire asynchronous JavaScript debug pure. Nella finestra attività è possibile visualizzare tutte le attività attive e completate in un dato punto nel codice dell'applicazione.
Per questo prossimo esempio, aggiungerò una nuova pagina per la soluzione di dimostrare questo fantastico strumento. Nella soluzione, creo una nuova cartella denominata chainedAsync nella cartella pagine e quindi aggiungere un nuovo controllo Page denominato chainAsync.html (che crea /pages/chainedAsync/chainedAsync.html e il file. js e CSS associati).
In chainedAsync.html, inserire il seguente codice all'interno della sezione < > Tag:
<!-- ERROR:Clicking this button starts a chain reaction with an error.
-->
<p><button id="startChain">Start the error chain</button></p>
<p id="output"></p>
In chainedAsync.js, aggiungere il gestore eventi illustrato Figura 7per l'evento click del pulsante startChain al metodo pronto per la pagina.
Figura 7 il contenuto della funzione PageControl.ready in chainedAsync.js
startChain.addEventListener("click", function () {
goodPromise().
then(function () {
return goodPromise();
}).
then(function () {
return badPromise();
}).
then(function () {
return goodPromise();
}).
done(function () {
// This *shouldn't* get called
},
function (err) {
document.getElementById('output').innerText = err.toString();
});
});
Ultima, è possibile definire le funzioni goodPromise e badPromise, mostrato Figura 8, all'interno di chainAsync.js quindi sono disponibili all'interno dei metodi di PageControl.
Figura 8 le definizioni delle funzioni goodPromise e badPromise in chainAsync.js
function goodPromise() {
return new WinJS.Promise(function (comp, err, prog) {
try {
comp();
} catch (ex) {
err(ex)
}
});
}
// ERROR: This returns an errored-out promise.
function badPromise() {
return WinJS.Promise.wrapError("I broke my promise :(");
}
Eseguire nuovamente l'esempio, passare alla pagina "Chained asincrono" e quindi fare clic su "Avvia la catena errore." Dopo una breve attesa, il messaggio "ho rotto la mia promessa: (" appare sotto il pulsante.
Ora devo rintracciare dove si è verificato l'errore e capire come risolvere il problema. (Ovviamente, in una situazione artificiosa come questa, so esattamente dove è verificato l'errore. Per scopi di apprendimento, dimenticherò che quel badPromise iniettato l'errore nel mio promesse incatenati.)
Per capire dove le promesse incatenate andare storto, ho intenzione di inserire un punto di interruzione il gestore di errore definito nella chiamata a fatto nel gestore click per il pulsante di startChain, come mostrato Figura 9.
.png)
Figura 9 la posizione del punto di interruzione in chainedAsync.html
Eseguire nuovamente lo stesso test, e quando tornerò da Visual Studio, l'esecuzione del programma ha fermato sul punto di interruzione. Successivamente, aprire la finestra attività (Debug | Windows | Compiti) per vedere quali compiti sono attualmente attivi. I risultati sono riportati Figura 10.
.png)
Figura 10 la finestra attività in Visual Studio 2013 mostrando l'errore
At in primo luogo, nulla in questa finestra spicca come aver causato l'errore. La finestra elenca cinque compiti, che sono contrassegnati come attivi. Come prendere uno sguardo più attento, tuttavia, vedo che uno dei compiti attivi è l'utilità di pianificazione in fila Errori promessa — e che sembra promettente (scusate il gioco di parole cattiva).
(Se ti stai chiedendo l'utilità di pianificazione, vi incoraggio a leggere il prossimo articolo di questa serie, di cui tratterò la nuova API Scheduler in WinJS).
Quando passa il mio mouse su tale riga (ID 120 in Figura 10) nella finestra attività, ottenere una visione mirata dello stack di chiamate per quel compito. Vedo diversi gestori di errori e, ecco, badPromise è quasi all'inizio dello stack di chiamate che. Quando io fare doppio clic su tale riga, Visual Studio mi porta destra per la riga di codice in badPromise che ha generato l'errore. In uno scenario reale, sarebbe ora diagnosticare perché badPromise era venga generato un errore.
WinJS fornisce diversi livelli di gestione degli errori in un app, di là del blocco try-catch-finally affidabile. Un buon rendimento app dovrebbe utilizzare un grado adeguato di gestione degli errori per fornire un'esperienza semplice per gli utenti. In questo articolo, dimostrato come incorporare errore app-livello, livello di pagina o navigazione gestione in un'app. Anche dimostrato come utilizzare alcuni dei nuovi strumenti in Visual Studio 2013 per rintracciare errori nelle promesse incatenati.
Nel prossimo articolo di questa serie, potrai esplorare alcune delle tecniche per realizzare applicazioni Windows Store eseguire meglio. Esamino sarò Web lavoratori, la nuova API Scheduler in WinJS 2.0 e il nuovo modello dispose in WinJS 2.0.
Eric Schmidt è uno sviluppatore di contenuti nella squadra contenuto dello sviluppatore di Microsoft Windows, scrivendo la libreria Windows per JavaScript (WinJS). In precedenza ha lavorato nella divisione Microsoft Office , dove ha costruito esempi di codice per le applicazioni per la piattaforma Office. Egli passa il tempo con la sua famiglia, suona il basso stringa, costruisce HTML5 video giochi e Blog sulla costruzione di giocattoli di plastica (historybricks.com).
Grazie ai seguenti esperti tecnici Microsoft per la revisione di questo articolo: Kraig Brockschmidt e Josh Williams
Kraig Brockschmidt è un Senior Program Manager del team di Windows ecosistema, lavorando direttamente con i partner comunitari e chiave di sviluppatore sulla creazione di applicazioni Windows Store. È autore di programmazione di applicazioni Windows Store in HTML, CSS e JavaScript (ora alla sua seconda edizione) e condivide altre intuizioni su http://www.kraigbrockschmidt.com/blog.
Josh Williams è principale Software Development Engineer Lead del team di Windows Developer Experience. Lui e il suo team costruito la libreria Windows per JavaScript (WinJS).