To be clear, I'm not saying you can't handle database problems. If there are situations where a recovery path is possible and worth the effort then by all means do that (that becomes an expected error now*). However, in a lot of cases it's not possible or simply not worth it since a retry mechanism is almost always better situated outside the…
You’re right. Panicking can be a lazy way to do error handling. However, that’s not what I'm advocating for here. Panicing under specific unrecoverable situations is OK.
To be clear panicking does not skip the deferred code — that is why we use a
defer to perform a
recover(). As mentioned in my reply to Dele, you must have a…
A panic should not mean it takes the whole service down. In fact, you absolutely must have a recover at the top level of the request. Most frameworks including the http package will give you this for free.
The panic on an unexpected error (that is, an error that has not reasonble recovery path) acts as a short circuit to…
Hi Vitaliy, publishing happens automatically for any package on Github (no setup or configuration requried). Whenever you push code to the master branch of a repository you should see the docs updated almost immediately after.
Thanks for the feedback Andres. I agree with everything you just said. Looking back I may have exagerated on a few things. I was new to blogging and still trying to find my voice.
Hi Sean, I’m glad you found it helpful. The library/tools support merging and querying, which should make it possible to merge portions of trees. I would suggest opening a github issue so we can discuss it further.
Also, you may want to checkout warnings. Perhaps it will catch some cases that your other applications did not: https://github.com/elliotchance/gedcom/wiki/Warnings