The changelog is a file that will show documentation for all notables changes to a project, thus making it easier to keep track of it evolution, growth and progress.

More often than not, this documentation is excesively synthetized, which means that no ellaborate descriptions are available for a given change inside of the file. This makes the translations efforts a little bit harder since we often need to add a few words on the source string to better translate each bullet point without messing the technical interpretation it needs to get.

While translating this segment of the changelog, most of its content made references to the ways Node.js handles errors when processing and building your code and during its common usage. To better understand this concept, let's talk about Error Handling.

Error handling refers to the resolution of programming and communication errors that were previously anticipated by the developer and detected by software. There are mainly two types of error to look for while managing error handling as a programmer: development errors and runtime errors.

Development errors are those caused by a human mistake and can be prevented when coding your software. This are mostly caused by a failure in either the syntax or the logic of the program that triggers them. A syntax error refers to improper use of the language characters or a typo in the instructions made. A logic error happens when the program's result is not the same as the intended result.

Runtime errors are those that are detected when the program is running and most of the time are caused by anomalies inside the input values or the data parameters inserted by the user, which means that the data set was not expected by the developer and therefore the program is not ready for it. Other common runtime errors are those caused by adverse system conditions, such as lack of memory, communication issues or a conflict with another software.

Error handling in Node.js is aimed at reducing the impact of runtime errors, which they call operational and unavoidable errors, by introducing a serie of instructions and countermeasures that allow the program to go back into its normal functionality. Node allows developers to handle errors either synchronously (with the throw function) or asynchronously (with a callback or event emitter), but not both.

- Languages

• Source Language: English
• Translated Language: Spanish

- Word Count

Number of words translated on this contribution: 1350 words, including a small number of coding instructions.

Proof of Authorship

The translation was submitted via CrowdIn and you can find all the related information on the following links.

Node.js Crowdin page

My Crowdin Profile
My Crowdin Activity
My Github Profile

- Examples sentences in Spanish:

• [<0>14bc3e22f3</0>] - <1>(SEMVER-MAJOR)</1> <1>domain</1>: runtime deprecate MakeCallback (Andreas Madsen) <2>#17417</2>

  • [<0>14bc3e22f3</0>] - <1>(SEMVER-MAJOR)</1> <1>domain</1>: desaprobar el tiempo de ejecución de MakeCallback (Andreas Madsen) <2>#17417</2>

• [<0>3154d83a02</0>] - <1>(SEMVER-MAJOR)</1> <1>src</1>: update postmortem constant name (cjihrig) <2>#17489</2>

  • [<0>3154d83a02</0>] - <1>(SEMVER-MAJOR)</1> <1>src</1>: actualizar el nombre de la constante postmortem (cjihrig) <2>#17489</2>

• [<0>2a61ce5996</0>] - <1>(SEMVER-MAJOR)</1> <1>src</1>: validate args length in Access and Close (Sakthipriyan Vairamani (thefourtheye)) <2>#18203</2>

  • [<0>2a61ce5996</0>] - <1>(SEMVER-MAJOR)</1> <1>src</1>: validar la longitud de los argumentos en Acceso y Cierre (Sakthipriyan Vairamani (thefourtheye)) <2>#18203</2>

Previous Spanish translations for the project: