206 } catch (cerr) {
207 console.error(cerr);
208 }
209 process.exit(1);210})
211const splchecker = new SpellChecker(new SpellCfg({ ignoreCase: false, languages: ['en-us'] }));
212splchecker.addProviderByConfig({ name: 'hunspell' });
185 process.exit(0);
186 } catch (err) {
187 console.error(err);
188 process.exit(1);189 }
190})
191process.on("uncaughtException", async (err) => {
182 embeds: [mbed],
183 });
184 }
185 process.exit(0);186 } catch (err) {
187 console.error(err);
188 process.exit(1);
9 readline.question("What's the URL/path of the avatar? ", url => {
10 bot.user.setAvatar(url).then(() => {
11 console.log("All done!")
12 process.exit(0)13 }).catch(e => { throw e })
14 })
15})
The process.exit() method in Node.js is used to immediately stop the Node.js process and exit. This is a dangerous operation because it can occur in any method at any point in time, potentially stopping a Node.js application completely when an error occurs. For example:
if (somethingBadHappened) {
console.error("Something bad happened!");
process.exit(1);
}
This code could appear in any module and will stop the entire application when somethingBadHappened is truthy. This doesn't give the application any chance to respond to the error. It's usually better to throw an error and allow the application to handle it appropriately:
if (somethingBadHappened) {
throw new Error("Something bad happened!");
}
By throwing an error in this way, other parts of the application have an opportunity to handle the error rather than stopping the application altogether. If the error bubbles all the way up to the process without being handled, then the process will exit and a non-zero exit code will returned, so the end result is the same.
If you are using process.exit() only for specifying the exit code, you can set process.exitCode (introduced in Node.js 0.11.8) instead.
process.exit(1);
process.exit(0);
Process.exit();
var exit = process.exit;