gcanti / docs-ts

A zero-config documentation tool for my TypeScript projects
https://gcanti.github.io/docs-ts/
MIT License
100 stars 17 forks source link

feat(cli): print error as non coerced string #28

Closed waynevanson closed 3 years ago

waynevanson commented 3 years ago

When coercing an error to a string, it converts to error.message.

The call stack is not displayed in this message, and it's the most critical part in debugging.

This is the quick fix. The next best thing is to have a --debug flag that switches between original implementation and this suggested implementation.

27

IMax153 commented 3 years ago

I am definitely open to this change!

However, I actually think that displaying a big red message stating that the Error in question was unexpected is useful for an end user.

Can we do something like:

main().catch((e) => {
  console.log(chalk.bold.red('Unexpected Error'))
  console.log(e)
})

What do you think?

waynevanson commented 3 years ago

I am definitely open to this change!

However, I actually think that displaying a big red message stating that the Error in question was unexpected is useful for an end user.

Can we do something like:

main().catch((e) => {
  console.log(chalk.bold.red('Unexpected Error'))
  console.log(e)
})

What do you think?

Aren't all errors unexpected? Surely when an error prints to the screen it's implied to not be non-desired behavior.

Sure, sounds good to me.

 main().catch((e) => {
   console.log(chalk.bold.red('Unexpected Error'))
-  console.log(e)
+  console.error(e)
+  process.exit(1)
 })

How does that sound?

IMax153 commented 3 years ago

Aren't all errors unexpected? Surely when an error prints to the screen it's implied to not be non-desired behavior.

Not really - I would consider any Left value returned by a TaskEither to be an expected error (i.e., it was a branch of program execution that was anticipated ahead of time). These expected errors are then handled within index.ts when the TaskEither is folded.

This is in contrast to an unexpected error which is unanticipated and must be handled via the catch clause in bin.ts.

How does that sound?

LGTM! Thank you!

waynevanson commented 3 years ago

@IMax153 Sorry about the delay.

~jest.it.each has some problems. I've noticed it in other libraries too. see latest commit, message for more details.~ Some kind of race conditions on dependencies, oh what a joy.

IMax153 commented 3 years ago

@gcanti, @gillchristian, @thought2, @waynevanson - Merged!

Thanks @waynevanson! 👍

gcanti commented 3 years ago

Thanks, released.