Why did startStackFunction get renamed to startStackFn from 8.x to 10.x #27671

Activity

1. BridgeAR commented on May 13, 2019

   

   BridgeAR

   on May 13, 2019

   Member

   More actions

   @Raynos that was a mistake on my side. I did not anticipate that the error class would actually really be used in the wild (it was not documented) and that this option would be used. I'll open a PR to accept both as valid options but that will probably not help a lot anymore.
2. BridgeAR

   added a commit that references this issue on May 13, 2019

   assert: add compatibility for older Node.js versions

   ...

   ebad0ae
3. BridgeAR commented on May 13, 2019

   

   BridgeAR

   on May 13, 2019

   Member

   More actions

   I'll try to backport this as well.
4. BridgeAR

   added

   assertIssues and PRs related to the assert subsystem.Issues and PRs related to the assert subsystem.

   on May 13, 2019
5. Raynos commented on May 14, 2019

   

   Raynos

   on May 14, 2019

   ContributorAuthor

   More actions

   @BridgeAR you are my hero.

   Here is my use case for context.

   'use strict'
   
   const process = require('process')
   const { AssertionError } = require('assert')
   
   module.exports = nextTickAssert
   
   function nextTickAssert (value, message) {
     let errorToBeThrown
   
     if (!value) {
       let generatedMessage = false
   
       if (arguments.length === 0) {
         generatedMessage = true
         message = 'No value argument passed to `assert.ok()`'
       } else if (message == null) {
         generatedMessage = true
         message = String(value) + ' == true'
       }
   
       if (message instanceof Error) {
         errorToBeThrown = message
       } else {
         const err = new AssertionError({
           message: message,
           actual: value,
           expected: true,
           operator: '==',
           stackStartFunction: nextTickAssert,
           stackStartFn: nextTickAssert
         })
         err.generatedMessage = generatedMessage
         errorToBeThrown = err
       }
   
       process.nextTick(() => {
         throw errorToBeThrown
       })
     }
   }
   

   I want to use assert() but somehow bail outside of async/await; I want sanity assertions that should never happen and fail my program.

   I'll open an issue / PR on node core for this seperately as it's a useful issue that came up on twitter a while ago.
6. BridgeAR commented on May 14, 2019

   

   BridgeAR

   on May 14, 2019

   Member

   More actions

   @Raynos I believe you actually want to use the --unhandled-rejections=strict mode in that case. That is not yet available in Node.js < 11.x but it should be backported to at least 10.x.
7. BridgeAR commented on May 14, 2019

   

   BridgeAR

   on May 14, 2019

   Member

   More actions

   An easier solution would also be the following:

   'use strict'
   
   const process = require('process')
   const assert = require('assert').strict
   
   module.exports = nextTickAssert
   
   function nextTickAssert (value, message) {
     try {
       assert(value, message)
     } catch (err) {
       Error.captureStackTrace(err, nextTickAssert);
       process.nextTick(() => {
         throw err
       })
     }
   }
8. Raynos commented on May 14, 2019

   

   Raynos

   on May 14, 2019

   ContributorAuthor

   More actions

   Your solution means i don't have an issue with the AssertionError constructor anymore. I didn't think about catching the error ...

   I'd have to write some benchmarks though. The existing assert() calls are mostly free because they are a single if branch on a boolean.
9. BridgeAR commented on May 14, 2019

   

   BridgeAR

   on May 14, 2019

   Member

   More actions

   @Raynos the cost should be identical in newer Node.js versions. I believe Node.js 8 is already fine with try / catch statements but I forgot in what version the performance cliff got removed.

   There is one significant difference between these two versions though: the error message will be different (in case no message argument was passed through). Due to the abstraction, assert is not going to be able to determine the actual call site anymore but you said you want this only as safe guard that should actually never trigger.
10. BridgeAR

    added a commit that references this issue on May 16, 2019

    assert: add compatibility for older Node.js versions

    ...

    e632b1b
11. BridgeAR

    closed this as completedin e632b1bon May 16, 2019
12. targos

    added a commit that references this issue on May 17, 2019

    assert: add compatibility for older Node.js versions

    ...

    6983a0c