feat(core): Modify BaseExceptionFilter to print exception properties

[jochongs]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

Issue Number: #13550 #13870

What is the new behavior?

First of all, I sincerely apologize for creating a new PR for the same issue. I couldn’t find the commit related to the previous approach of using the inspect utility function in #13870, so I created a PR.

In #13870, the combineStackTrace method was used to trace the cause of Error. However, it does not output other properties of the error object as intended by the code author.

While I agree that it's important to print the cause property of the Error, I also believe that other properties should be printed as well.

Below is an example of an error that occurred with the database using the pg library. It includes a code to identify the error and hints for debugging.

node_modules/pg-protocol/src/parser.ts:369
      name === 'notice' ? new NoticeMessage(length, messageValue) : new DatabaseError(messageValue, length, name)
                                                                    ^
error: terminating connection due to administrator command
    at Parser.parseErrorMessage (/Users/kpturner/fotech/panoptes-ui-prototype/node_modules/pg-protocol/src/parser.ts:369:69)
    at Parser.handlePacket (/Users/kpturner/fotech/panoptes-ui-prototype/node_modules/pg-protocol/src/parser.ts:188:21)
    at Parser.parse (/Users/kpturner/fotech/panoptes-ui-prototype/node_modules/pg-protocol/src/parser.ts:103:30)
    at Socket.<anonymous> (/Users/kpturner/fotech/panoptes-ui-prototype/node_modules/pg-protocol/src/index.ts:7:48)
    at Socket.emit (node:events:390:28)
    at Socket.emit (node:domain:475:12)
    at addChunk (node:internal/streams/readable:315:12)
    at readableAddChunk (node:internal/streams/readable:289:9)
    at Socket.Readable.push (node:internal/streams/readable:228:10)
    at TCP.onStreamRead (node:internal/stream_base_commons:199:23) {
  length: 116,
  severity: 'FATAL',
  code: '57P01',
  detail: undefined,
  hint: undefined,
  position: undefined,
  internalPosition: undefined,
  internalQuery: undefined,
  where: undefined,
  schema: undefined,
  table: undefined,
  column: undefined,
  dataType: undefined,
  constraint: undefined,
  file: 'postgres.c',
  line: '2925',
  routine: 'ProcessInterrupts'
}

As shown in the example above, I believe it would be useful for debugging if other property values of the error object are printed.

I would like to ask for your opinion on this issue.

Does this PR introduce a breaking change?

• Yes
• No

Other information

(I wasn’t sure whether to leave this in the issue section or the PR section, so I left it in the PR section to show the code changes. I apologize if it should have been in the issue section instead.)

[coveralls]

Pull Request Test Coverage Report for Build 5fc596c1-720d-4b81-ad14-df3d78831a3e

Details

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.001%) to 92.209%

---

Totals
Change from base Build c9b17776-8993-4d3d-9083-ccfdef03782e:	0.001%
Covered Lines:	6746
Relevant Lines:	7316

---

💛 - Coveralls

[benjGam]

Hi, would be possible to let the choice ?
I think to something like 'verbose' boolean property (it could be a parameter in constructor with default value as 'false' to do not introduce breaking change).

It could be useful to implement this, like that, you do not force anyone to get long trace message.

EDIT: It's a good change anyway ! Thanks

[jochongs]

@benjGam

This PR is simply a PR written for code comparison. I think it would be good to track it in #13870.