It's arguable. Exceptions give you a somewhat clean way of pattern match their
type and dealing with failures in a single place in an uniform way. Ex having
to deal with not ok http status codes and then a potential low level networking
exception at the same level is good imho.
I tend to use e
There is one context where failure as exceptions can be a bit ugly is in core
async channels but there are a few ways to deal with this, from separating
channels for exceptions, using some kind of named tuple, map or just
dispatching with instance? It is just a side effect of core async design w
>
> Thanks for pointing out the submit function and explaining the wrapper.
>> Would you specifically advise against sending the result back through a
>> channel?
>>
>
> It depends what you're trying to do. What are you doing with the result,
> and what's your reasoning for not handling it in your
Hi Erik,
It hadn't even crossed my mind that I could write a separate app which is
trigged by cron. I will consider that! I have searched for different
schedulers and found a few options but cannot locate any in Juxt's github
repositories. I've read about transducers and think that I've got a
supe
> Given that the examples you provided are from typed languages and Clojure
> isn’t typed, what would satisfy you here?
>
Well... static types have absolutely nothing to do with errors handling
mechanics. That's just a way for your compiler to check if you glue all
pieces together in a reaso
If I was building a system like the one you describe for real, then the
first tool I'd reach for would be a email sending service, like Mailgun,
Sendgrid, or AWS SES. These sorts of services take care of queuing mail,
retrying on failure, and keeping track of mail bounces. They also all have
free t
