Hello everyone, time for another Pathom update!
The new Pathom 3 Documentation Website is out!. I’m going to expand the documentation as I write features in Pathom. With the current content, I expect users to be able to play with Pathom 3. If you are curious about Smart Maps or any other feature I mentioned before, go check it out!
The current progress:
- Getting Started
- Using Pathom
- Built-in resolvers
- Smart Maps
- How Pathom Works
- Shape Descriptor
I’m currently writing the docs for the planner and runner.
I started to explore how to make the error handling in Pathom 3. There are two main contexts in which errors may happen:
- Resolver error - something went wrong while calling some resolver
- System error - something went wrong in Pathom code during the process
Currently, systems errors are always going to flow up and stop the running process. Resolver errors are not; they are silent by default.
Since Pathom always process multiple items at once, it’s crucial to determine what errors the user is looking for. A common need to lookup an error for some attribute.
An attribute error may happen in a couple of different ways:
- The resolver responsible for the attribute had an error
- Some dependency of the attribute had an error
- The attribute had multiple options, and some all of them resulted in errors
The last option has another twist, what if some options failed? Do you want to see these errors? The answer will vary on a case-by-case basis.
So what Pathom does is record the errors in the node that they happen. Then the user can use this data (which also provides the graph) to crunch error details.
Part of this work provides primitives to make it easier to ask error questions given the node’s error data. For example, finding the error for a given attribute.
Nothing is set in stone at this moment. This is a time for exploring ideas and see how they end up. If you have ideas about Pathom error handling, please start a conversation at #pathom on Clojurians.
Now with the new error primitives, it’s possible to start reporting errors from Smart Map lookups.
There is now a
psm/with-error-mode helper to configure error reporting. By default,
errors will remain
silent, respecting the expectation that map lookups are not supposed to throw exceptions.
Turning it into
loud error mode will change this behavior:
(-> (psm/smart-map (psm/with-error-mode env ::psm/error-mode-loud)) :read-error) ; throw exception
Smaller update, now Smart Maps property support
On the last updated I mentioned the planner debugger, it got some updates and its now animated:
More details about this will come on the documentation page for the planner. Stay tuned!
New built-in resolvers add to the collection:
constantly-fn-resolver: similar to
constantly-resolver, but evaluates a fn to get the value
global-data-resolver: similar to
end-file-resolver, but provide the data directly
You can find documentation for all built-in resolvers in this page.
Support my work
I'm currently an independent developer and I spent quite a lot of my personal time doing open-source work. If my work is valuable for you or your company, please consider supporting my work though Patreon, this way you can help me have more available time to keep doing this work. Thanks!
And here I like to give a thanks to my current supporters: