robertbira

Italian Translation Report: Node.js [Part 5 - 1036 words]

Jul 15th, 2018
76
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. The second approach is to try to handle the exception.
  2. There will be cases
  3. where the native code can catch the exception, take the appropriate action,
  4. and then continue.
  5. This is only recommended in specific cases
  6. where it is known that the exception can be safely handled.
  7. In these
  8. cases can be used to get and
  9. clear the exception.
  10. On success, result will contain the handle to
  11. the last JavaScript
  12. If it is determined, after
  13. retrieving the exception, the exception cannot be handled after all
  14. it can be re-thrown it with where error is the
  15. JavaScript object to be thrown. thrown.
  16. The following utility functions are also available in case native code
  17. needs to throw an exception or determine if a is an instance
  18. of a JavaScript object: and
  19. The following utility functions are also available in case native
  20. code needs to create an object: and
  21. where result is the that refers to the newly created
  22. JavaScript object.
  23. The Node.js project is adding error codes to all of the errors generated internally. The goal is for applications to use these error codes for all error checking. The associated error messages will remain, but will only be meant to be used for logging and display with the expectation that the message can change without SemVer applying. In order to support this model with N-API, both in internal functionality and for module specific functionality (as its good practice), the and functions take an optional code parameter which is the string for the code to be added to the error object. If the optional parameter is then no code will be associated with the error. If a code is provided, the name associated with the error is also updated to be:
  24. where is the original name associated with the error
  25. and is the code that was provided.
  26. For example if the code
  27. is and a is being created the name will be:
  28. The environment that the API is invoked under.
  29. The JavaScript value to be thrown.
  30. Returns if the API succeeded.
  31. This API throws the JavaScript value provided.
  32. Optional error code to be set on the error.
  33. C string representing the text to be associated with
  34. the error.
  35. This API throws a JavaScript with the text provided.
  36. The to be checked.
  37. Boolean value that is set to true if represents
  38. an error, false otherwise.
  39. This API queries a to check if it represents an error object.
  40. Optional with the string for the error code to
  41. be associated with the error.
  42. that references a JavaScript to be
  43. used as the message for the
  44. representing the error created.
  45. returns
  46. The exception if one is pending, otherwise
  47. This API returns true if an exception is pending.
  48. This API can be called even if there is a pending JavaScript exception.
  49. Boolean value that is set to true if an exception is pending.
  50. The error you want to pass to
  51. Trigger an in JavaScript.
  52. Useful if an async
  53. callback throws an exception with no way to recover.
  54. Fatal Errors
  55. In the event of an unrecoverable error in a native module, a fatal error can be
  56. thrown to immediately terminate the process.
  57. Optional location at which the error occurred.
  58. The length of the location in bytes, or
  59. if it is null-terminated.
  60. The message associated with the error.
  61. The function call does not return, the process will be terminated.
  62. Object Lifetime management
  63. As N-API calls are made, handles to objects in the heap for the underlying
  64. VM may be returned as
  65. These handles must hold the
  66. objects 'live' until they are no longer required by the native code,
  67. otherwise the objects could be collected before the native code was
  68. finished using them.
  69. As object handles are returned they are associated with a
  70. 'scope'.
  71. The lifespan for the default scope is tied to the lifespan of the native method call. The result is that, by default, handles remain valid and the objects associated with these handles will be held live for the lifespan of the native method call.
  72. In many cases, however, it is necessary that the handles remain valid for either a shorter or longer lifespan than that of the native method. The sections which follow describe the N-API functions than can be used to change the handle lifespan from the default.
  73. Making handle lifespan shorter than that of the native method
  74. It is often necessary to make the lifespan of handles shorter than the lifespan of a native method. For example, consider a native method that has a loop which iterates through the elements in a large array:
  75. This would result in a large number of handles being created, consuming substantial resources. In addition, even though the native code could only use the most recent handle, all of the associated objects would also be kept alive since they all share the same scope.
  76. To handle this case, N-API provides the ability to establish a new 'scope' to which newly created handles will be associated. Once those handles are no longer required, the scope can be 'closed' and any handles associated with the scope are invalidated. The methods available to open/close scopes are and
  77. N-API only supports a single nested hierarchy of scopes. There is only one active scope at any time, and all new handles will be associated with that scope while it is active. Scopes must be closed in the reverse order from which they are opened. In addition, all scopes created within a native method must be closed before returning from that method.
  78. Taking the earlier example, adding calls to and would ensure that at most a single handle is valid throughout the execution of the loop:
  79. do something with element
  80. When nesting scopes, there are cases where a handle from an inner scope needs to live beyond the lifespan of that scope. N-API supports an 'escapable scope' in order to support this case. An escapable scope allows one handle to be 'promoted' so that it 'escapes' the current scope and the lifespan of the handle changes from the current scope to that of the outer scope.
  81. The methods available to open/close escapable scopes are and
  82. The request to promote a handle is made through which can only be called once.
RAW Paste Data

Adblocker detected! Please consider disabling it...

We've detected AdBlock Plus or some other adblocking software preventing Pastebin.com from fully loading.

We don't have any obnoxious sound, or popup ads, we actively block these annoying types of ads!

Please add Pastebin.com to your ad blocker whitelist or disable your adblocking software.

×