pathom

:pathom: https://github.com/wilkerlucio/pathom/ & https://pathom3.wsscode.com & https://roamresearch.com/#/app/wsscode
markaddleman 2020-12-12T23:40:37.480700Z

I'm starting to look at Pathom3. I notice that resolver exceptions are swallowed. This is just an unfinished piece of p3 or is there some magic I should put into the environment so that exceptions are percolated?

wilkerlucio 2020-12-13T16:27:35.482100Z

hello, its an unfinished piece, in Pathom I've seen different ways people need error information, the smart map for example, since it does a "per attribute" request, its possible to have the loud error mode, but for EQL the answer may vary. the first thing to consider is that "partial errors" are a big thing, since pathom has control over the process a lot can happen inside, and how to report the failure depends on your app needs. For instance, for front-end applications, its probably interesting to check at attribute level to see what worked and what failed. but for monitoring you may wanna know every error that happen. there is also the case of errors in OR branches, where an error may had happened, but another path worked, in this case, this should be reported as an error? sorry the big blog of text, I'm dumping the current thoughs on the error handling on Pathom, feedback and ideas are very welcome

wilkerlucio 2020-12-13T16:28:14.482300Z

so my guess its will end up with a few differnet API to handle the different cases, so its silent by default, but with accessors for different needs

markaddleman 2020-12-13T19:51:14.485400Z

No worries. I appreciate the insight. I certainly see the need for multiple approaches for errors.

markaddleman 2020-12-12T23:51:20.480800Z

i see that sm-get-with-stats provides a way of obtaining the exception