refactor: `hamilton.exceptions`

[zilto]

Given the increasing complexity of the library, it could be valuable to create custom exceptions rather than generic ValueError and KeyError.

This helps with:

• readability: the name of the exception is informative EdgeTypeMismatchException, UnknownNodeException, MaterializationError
• maintainability: the exceptions can be gradually improved by modifying the message in a central place instead of attaching custom messages to individual KeyError around the codebase
• debugging: maintainers and users can make a better use of the debugger and exception handling to debug and test their code

related:

• fix: Better error for @pipe without step() #1218

[rahul0906]

@zilto Imma new to open source but with pretty good experience in ML and python. Seems easy, should I take this up?

[skrawcz]

Thanks @rahul0906 yes it would be, but we haven't figured out alignment on this from a project perspective.

E.g.

1. we don't special case exceptions - nor do we need to catch and treat different exceptions.
2. It's really a trade off between a "named exception", and putting the contents of the error in ValueError exception for example...

Did you take a look at the "good first issue" labeled ones? Or?