Requesting descriptive errors explaining what went wrong with a request, or even what likely went wrong

[rolandm2017]

Issue Creation Checklist

• I understand that my issue will be automatically closed if I don't fill in the requested information
• I have read the contribution guidelines

Feature Description

Describe the feature you'd like to see implemented

I want Sequelize to throw accurate errors describing what I did wrong with the tool to cause the error. The problem is usability. The requested feature would solve lots of hassles with using the product.

Describe why you would like this feature to be added to Sequelize

There are libraries that give accurate, informative responses to misuses of the product. Improving Sequelize's UX = sequelize will be used and recommended more = the hard work everyone puts into the project will get more benefit.

I'll give you what looks to me like a doable example that would immediately benefit your users: suppose the user doesn't authenticate with the db before trying to use a .create() method. Why can't the program raise an error: "you know you haven't authenticated yet, right?" You could add a flag within the package "hasSuccessfullyAuthenticated" and "if (!successfulAuthentication)" throw the error.

Is this feature dialect-specific?

• No. This feature is relevant to Sequelize as a whole.
• Yes. This feature only applies to the following dialect(s):

Would you be willing to resolve this issue by submitting a Pull Request?

• Yes, I have the time and I know how to start.
• Yes, I have the time but I will need guidance.
• No, I don't have the time, but my company or I are supporting Sequelize through donations on OpenCollective.
• No, I don't have the time, and I understand that I will need to wait until someone from the community or maintainers is interested in implementing my feature.

I would try to make these changes myself if my project backlog wasn't so bad.

---

Indicate your interest in the addition of this feature by adding the 👍 reaction. Comments such as "+1" will be removed.

[ephys]

I understand the sentiment, and having clear and actionable error messages (when it's possible for us to do so) is one of our design goals and something that's being slowly improved.

However I can't approve the feature request because it doesn't have a clearly defined finite objective - it'd stay open forever.

If you have specific error messages that need to be improved, consider opening feature requests for these instead.

For instance, I assume what you mean about not using create before calling authenticate is about this #15267 ?

[github-actions]

This issue has been automatically marked as stale because it has been open for 14 days without activity. It will be closed if no further activity occurs within the next 14 days. If this is still an issue, just leave a comment or remove the "stale" label. 🙂

[jedwards1211]

@ephys could Sequelize just JSON.stringify()ing the additional properties into the error message if nothing else? Or let us set a flag that will make all error classes do that?

I hate errors coming from Sequelize so, so much because they almost never help me understand what went wrong. It can be such a time suck. I need a blanket solution to help me be more productive.

[jedwards1211]

I guess if nothing else I could just make some code monkeypatch the behavior I want onto Sequelize error classes.

[jedwards1211]

Okay, this is partly my goof in that I had some places logging error.message or error.stack instead of just passing the error directly to console.error, which would print out the additional properties. There is one case where I need to serialize any error and send it from a child process to a parent process, and Sequelize errors are definitely not great for that, though luckily in that case I can send util.inspect(error) instead of error.message or error.stack.