try {
  throw "I'm Evil"
  console.log("You'll never reach to me", 123465)
} catch (e) {
  console.log(e); // I'm Evil
}

Antwoord 3, autoriteit 33%

Het volgende artikel gaat misschien wat dieper in op wat een betere keuze is; throw 'An error'of throw new Error('An error'):

http ://www.nczonline.net/blog/2009/03/10/the-art-of-throwing-javascript-errors-part-2/

Het suggereert dat de laatste (new Error()) betrouwbaarder is, aangezien browsers zoals Internet Explorer en Safari (niet zeker van versies) het bericht niet correct rapporteren bij gebruik van de eerste.

Als je dit doet, wordt er een fout gegenereerd, maar niet alle browsers reageren zoals je zou verwachten. Firefox, Opera en Chrome geven elk een bericht ‘niet-afgevangen uitzondering’ weer en nemen vervolgens de berichtreeks op. Safari en Internet Explorer geven gewoon een “niet-afgevangen uitzondering” -fout en geven de berichtreeks helemaal niet. Dit is duidelijk suboptimaal vanuit het oogpunt van foutopsporing.

Antwoord 4, autoriteit 17%

Je vermeldt eerst deze code:

throw new Error('sample')

en dan schrijf je in je eerste voorbeeld:

throw new Error({'hehe':'haha'}) 

Het eerste Error-object zou eigenlijk handig zijn, omdat het een tekenreekswaarde verwacht, in dit geval ‘sample’. De tweede zou niet zijn omdat je een object probeert door te geven, en het een string verwacht, en zou geen nuttige fout weergeven.

Het error-object zou de eigenschap ‘message’ hebben, wat ‘sample’ zou zijn.

Antwoord 5, autoriteit 14%

TLDR: ze zijn equivalent Error(x) === new Error(x).

// this:
const x = Error('I was created using a function call!');
​​​​// has the same functionality as this:
const y = new Error('I was constructed via the "new" keyword!');

bron: https://developer.mozilla .org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error

throw en throw Error zijn functioneel equivalent. Maar als je ze vangt en ze serialiseert naar console.log, worden ze niet op precies dezelfde manier geserialiseerd:

throw 'Parameter is not a number!';
throw new Error('Parameter is not a number!');
throw Error('Parameter is not a number!');

console.log (e) van het bovenstaande produceert 2 verschillende resultaten:

Parameter is not a number!
Error: Parameter is not a number!
Error: Parameter is not a number!

Antwoord 6, Autoriteit 10%

De ErrorConstructor wordt gebruikt om een ​​foutobject te maken. Foutobjecten worden geworpen wanneer runtime-fouten optreden. Het foutobject kan ook worden gebruikt als basisobject voor door de gebruiker gedefinieerde uitzonderingen.

Door de gebruiker gedefinieerde fouten worden via de throwverklaring gegooid. Programmabesturing wordt doorgegeven aan de eerste catchblok in de oproepstack.

Het verschil tussen het gooien van een fout met en zonder foutobject:

throw {'hehe':'haha'};

In Chrome Devtools ziet er als volgt uit:

Chrome vertelt ons dat we een niet-afgevangen fout hebben die gewoon een JS-object is. Het object zelf zou informatie kunnen hebben over de fout, maar we weten nog steeds niet meteen waar het vandaan kwam. Niet erg handig wanneer we aan onze code werken en debuggen.

throw new Error({'hehe':'haha'}); 

In Chrome Devtools ziet er als volgt uit:

Een fout die is gegooid met het foutobject geeft ons een stapel trace wanneer we het uitbreiden. Dit geeft ons waardevolle informatie waarbij de fout precies vandaan kwam, vaak waardevolle informatie is bij het debuggen van uw code. Merk nog eens op dat de fout zegt [object Object], dit komt omdat de ErrorConstructor een berichtstring verwacht als een eerste argument. Wanneer het een object ontvangt, dwingt het in een touw.

Antwoord 7, Autoriteit 6%

u kunt throwals object

throw ({message: 'This Failed'})

Dan bijvoorbeeld in uw try/catch

try {
//
} catch(e) {
    console.log(e); //{message: 'This Failed'}
    console.log(e.message); //This Failed
}

of gooi gewoon een stringfout

throw ('Your error')
try {
//
} catch(e) {
    console.log(e); //Your error
}
throw new Error //only accept a string

Antwoord 8, Autoriteit 2%

Reactiegedrag

Afgezien van de rest van de antwoorden, zou ik een verschil in reageren willen laten zien.

Als ik een new Error()gooi en ik ben in de ontwikkelingsmodus, krijg ik een foutscherm en een console-logboek. Als ik een string letterlijk gooi, zal ik het alleen in de console zien en misschien missen, als ik het console-logboek niet kijk.

Voorbeeld

Het gooien van een foutmeldingen in de console en toont een foutscherm terwijl in de ontwikkelingsmodus (het scherm niet zichtbaar is in de productie).

throw new Error("The application could not authenticate.");

Terwijl de volgende code alleen inlogt op de console:

throw "The application could not authenticate.";

Antwoord 9

Dit is vrij oud, maar hopelijk kan iedereen die dit zoekt hier nog van leren:

Eerst en beroemd hebben we in javascript iets dat Primitive Wrapper wordt genoemd; een primitieve wrapper neemt primitieve gegevens en vertegenwoordigt deze in een objectformaat door simpelweg het “constructorpatroon” te gebruiken. Toch kunt u in primitieve wrappers besluiten om uw gegevens te laten retourneren als een objecttype of u kunt deze laten retourneren als het primitieve type (in deze situatie krijgt u nu een doorgaand commando voor javascript om de primitieve waarde te extraheren en in dit geval gebruikt u het nieuwe zoekwoord niet).

Samengevat:

1. gooi “Mijn fout”: dit creëert een Error-object en retourneert de primitieve gegevens die zijn geëxtraheerd uit het constructor “this”-object. En als je probeert het typeof in het catch-blok te controleren, vertelt het je dat het een primitief type “string” is

2. throw new Error(“Mijn fout”): dit geeft je een object waar je toegang hebt tot de foutwaarde van de message property. Wat hier gewoon gebeurt, is dat het “nieuwe sleutelwoord” een “this” object construeert en er “{name:”Error”,message:”…”}” aan toewijst en het teruggeeft. En wanneer u probeert het typeof van het catch-blok te controleren, ziet u een typeof “object”.

OPMERKING: In een situatie waarin u expliciet een aangepast object doorgeeft aan de worp, gedraagt ​​het zich alsof u de constructor heeft ingeroepen met behulp van het nieuwe sleutelwoord en daarom zal het vangstblok u het aangepaste object retourneren en niet de eigenschap van het bericht waarde. Bijvoorbeeld: gooien {Naam: “RangeErerRor”, Message: “Range is buiten de scope”, omgeving: “is gebeurd in het testen van functie”}.

Gebruik in conclusie wat u ook past, u weet wat u doet. Maar voor mij als ik niet veel gegevens nodig heb, maar eerder alleen de fout, dan ga ik voor primitieve terugkeer.

Antwoord 10

throw somethingwerkt met zowel object als strings. Maar het is minder ondersteund dan de andere methode. throw new Error("")werkt alleen met snaren en bochten objecten in nutteloos [Object obj] in het vangstblok.

Antwoord 11

TLDR

throw new Error('problem')vangt een aantal eigenschappen van de plaats waar de fout is gebeurd.

throw 'problem'NIET

new Error('message')VASTE DE UITVOERING STAPEL + ANDEREN

Met behulp van een foutobject kunt u de execution-stapel vastleggen op het punt waarop u de fout gooit. Dus wanneer de fout wordt doorgegeven aan de foutenverwerkingstructuur, dus deze stapel snapshot.

Inzetten van throw "test error"Ergens in mijn codebase Resultaten in:

Terwijl throw new Error('test error')resulteert in:

U kunt zien dat het Native-foutobject de stapel vangt op het punt dat ik de fout gooi en het beschikbaar maakt voor alles wat de fout is vastgelegd. Dat maakt het gemakkelijker voor mij om het probleem te traceren als ik het debuggen.

Daarnaast plaatst het ook eigenschappen zoals fileName, lineNumberEN columnNumber.

Exception Loggers Capture the Stack Trace voor u

In dit geval wordt de stapel in de browserconsole afgedrukt, maar als u JavaScript-foutmeldingstools zoals Appsignal of BugSnag gebruikt, zal die stapel ook ook in hen beschikbaar zijn. Als u het foutobject inspecteert, heeft u rechtstreeks toegang tot de stapel Snapshot:

err = new Error('test')
err.stack

Wanneer u wilt gebruiken welk foutformaat

Uitzonderingen die u van plan bent om te vangen, kan eenvoudig zijn: throw 'problem'

Als de fout die u gooit een verwachte fout is die u van plan bent om te vangen en te handelen, dan wordt u niet veel gebruik uit de stapelmomentopname.

Laten we zeggen dat u een HTTP-service gebruikt en het retourneert een 500 HTTP-code. U kunt dit behandelen als een fout die u throw {responseCode=500}en vervolgens vervolgens vangen en handvat.

Uitzonderingen U bent niet van plan om te vangen moet new Error('problem')

gebruiken

Als u een fout gooit omdat er iets onverwachts of buiten de grenzen in de toepassing is gebeurd, laten we zeggen dat de lokale datastore is beschadigd, u bevindt zich in een situatie waarin u het niet wilt, maar je wilt het markeren. In dit geval is het een goed moment om het foutobject te gebruiken, zodat u die stapelmomentopname hebt.

Door het gebruik van throw new Error('Datastore is corrupted')het is gemakkelijker om je weg terug te traceren naar wat er is gebeurd.