Maybe @UJVEQPAKS?

ah damn, I see it now. The hx-target needs to be in quotes

Sorry for the interruption

Yeah - htmx shouldn’t need any special treatment in hiccup.

This is a known issue - there was a bug in the indexer we use that has added some junk. Hope to have it fixed soon

great sorry for the noise then ! thanks

You don't have to add it. As the docstring says, you can even have (cond) which returns nil.

How about adding it as a message that the previous statements don't cover all the possibilities? In a sense, omitting :else nil indicates that nil cannot be returned as a result of that cond

Personally, I wouldn't do it and would remove it in any code that I own. It's just noise.

I very often do :else (assert nil) which is an extremely lazy way to signal that the conditions in the cond should be exhaustive

Ah, if you want to fail on a non-match, then yeah. I manage to force myself to use ex-info. :D

I usually do (throw (ex-info ...)) but (assert nil) is very clever

Thank you for your help!

@U0NCTKEV8 @UEENNMX0T I wrote this some eons ago, maybe it is useful to somebody: https://bytopia.org/2016/10/15/beware-of-assertions/ Basically, assert throws an Error, not an Exception, and this might be a problem sometimes.

Well aware, yes I always catch throwable

Aren't assert disabled sometimes as well?

Alex' article doesn't acknowledge that you can simply

(try
  (catch Exception e
    ,,,)
  (catch AssertionError e
    ,,,))

re OP, :else nil is defensible. It signals to maintainers that the author didn't forget to add an :else (which does happen)

I have to say: it is very bad to catch Throwable everywhere, and you should carefully consider in each case whether to use an assertion or throw an ex-info. Use ex-info for situations that may arise as a result of user error, network failures, or other expected error conditions. Use assert for situations that indicate programmer error and which cannot come up otherwise (e.g. can only come up if an argument or return value doesn't match the spec it claims, a codepath is unreachable, etc).

In cases where someone has made an incorrect decision about which to use and as a result assertion errors are being thrown in an expected error case, always catch AssertionError and never catch Throwable.

The reasoning for this the generalization of what vemv was referring to: Error is noted by the JVM as specifically being for throwables which no sane program should attempt to catch. The only general-purpose exception to the rule that catching Throwable or Errors is a code smell is in task dispatch frameworks that need to keep the thread alive in case of a failure.

Obviously there may be other exceptions to that general rule but they should be evaluated on a case-by-case basis and strongly favor being specific.

(I'll also admit that I may be a bit more dogmatic about not catching Throwable than most, because I am the author of a library that relies on Error not being caught in random places to function correctly)

It's cool, I don't use your library

https://clojurians.slack.com/archives/C03S1KBA2/p1618117645329200

It's not like my library is the only thing that uses errors. ThreadDeath, OutOfMemoryError, StackOverflowError, LinkageError, and others are all things that extend Error and are highly likely to produce undesirable behavior if you catch them.

> An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. There's a reason this is the very first line of the Error javadoc.

sure, and your Error indicates a "serious problem that a reasonable that a reasonable application should not try to catch" right? you don't catch it right?

Obviously my personal usecase is outside that domain, it's hijacking that property, and I see no issue with people avoiding my library because of it. It's simply the fact that making the library pushed me to research this topic more that has exposed me to these other issues that I believe anyone who wants to write reliable software on the JVM should care about, regardless of if they happen to use my library.

I don't typically catch Throwable inside the code, but at the boundary, absolutely. Around APIs, or command inputs, etc. You don't want a throwable crashing your server for no good reason.

babashka http-client supports it (any library built on java.net.http does I think like hato, etc), also http-kit supports it

Speaking from experience, Aleph is the most mature solution, but learning to use it properly is a long journey.

For client stuff, I have done a lot of https://github.com/dakrone/clj-http and it was complicated to use (async flavor) and painful (I just want a wall-clock timeout on my request 😞) thank to the clunky Apache Http API. These days, I just roll https://github.com/http-kit/http-kit it is easy to use and just works.

httpkit is always the one I end up back too. The others always give me some issues here and there

for async http handlers, ive been messing around with pedestal + jetty and its a breath of fresh air compared to ring-based solutions

are we talking http client or server?

client

clj-http's async flavor is... odd

normally i reach for http-kit for this kind of thing, but im also using datadog tracing and http-kit's client isn't included in their automatic instrumentation

as a result im now looking at hato

which relies on the java 11 httpclient, which is datadog supported

I had an issue with the babashka http client, switched to http-kit, issue was gone, wished I had filed an issue, but now I can't remember