That is probably because the compilation unit of Clojure is a form, not a file or a namespace

Probably also related to this https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd697f#why-clojure-compiler-is-single-pass-arent-many-possible-optimizations-lost-this-way

what pain is experienced by “too many” class files?

> what pain is experienced by “too many” class files? I was working on byte code to wasm - so there were too many class files that caused some problems

what problems?

As an example:

$ clj -M -e "(defprotocol Interceptor (interceptor [x])) (extend-protocol Interceptor clojure.lang.IRecord (interceptor [_] :rec) clojure.lang.IPersistentMap (interceptor [_] :map))  (defrecord Foo []) (interceptor (->Foo))"

$ clj -M -e "(defmulti interceptor type) (defmethod interceptor clojure.lang.IRecord [_] :rec) (defmethod interceptor clojure.lang.IPersistentMap [_] :map)  (defrecord Foo []) (interceptor (->Foo))"

Multiple methods in multimethod 'interceptor' match dispatch value: class user.Foo -> interface clojure.lang.IPersistentMap and interface clojure.lang.IRecord, and neither is preferred

I think in the case of the protocol fast path that uses java interfaces, supporting some preference mechanism there might have a large performance penalty

I am pretty sure there is a jira somewhere

What I'm looking for is actually to disable the preference mechanism for my defined multi-method, to get the same behavior

You can see how clojure.core documents this:

clojure.core/even?
([n])
  Returns true if n is even, throws an exception if n is not an integer

Good data point. Is that what you would do too?

Yeah. There's no exception checking so putting it in metadata is making it more difficult for humans and easier for programs when no program checks it

For this sort of reason I'd favor Results over exceptions where possible. You can integrate Results with spec or malli, whereas exceptions will completely escape those "type systems", which drastically decreases their usefulness IMO

What do you mean "Results"? Does that mean just returning a value. E.g hashmap?

nope, but almost. it's a wrapper which can be a hashmap https://en.wikipedia.org/wiki/Result_type (or you can return the same hashmap you would usually return - if it lacks an :error key, you could infer it's not an Error) there are a few libs like this in clj (you can google for "railway oriented clojure site:http://github.com"). and it's simple enough to roll your own

https://github.com/fmnoise/flow is a recent simple enough library that supports writing Railway like code.

Flow is nice, although it's exception-based which goes against my initial point IME using spec/malli/schema in large codebases, exception handling just cannot be an afterthought, else your investment will be less fruitful where it matters the most (if someone gets to knot between Flow and spec/etc... great :) I'm afraid that it doesn't exist today, and seems a hard problem to solve)

Not sure what you mean by "exception based being against the initial point". The exception (either created by Java code or created by us, possibly without the overhead of a stack-trace) is returned as a value. The exception class is reused as a placeholder for a failure value.

If I got its readme correctly, it still encourages you to throw things

ex-info and the library's own fail-with only create an Exception instance. Most of the examples simply return the exception instance as a value. Some of the examples in the readme do use a throw to demonstrate that if some code does throw an exception, the libraries functions will catch the exception and return it as a value.

So it seems both approaches are allowed? throw or return an ex. That flexibility is cool but I'd favor banning exceptions from business code altogether (also, sorry if I deviated this thread a little)

I do not think exceptions and throwing of those exceptions are equivalent. An exception is really just another data structure, with semantic indication of failure, and a stack trace that can potentially be very useful for diagnosing said failure. Throwing that exception is like running into a theater screaming "fire!" A thrown exception is a stop-the-world demand for a attention with no early warning from the function signature. So there is definitely promise in catching exceptions to pass along as values (e.g. wrapped in what you call a Return type), instead of implicitly rethrowing. But sometimes when code is a middle-man between a consumer and something that throws, it seems sensible to just pass that along, instead of trying to handle it with insufficient knowledge. Maybe the consumer will use your function in a way that cannot possibly trigger an exception. Maybe the usage of a function is clear enough that you can realistically enforce compliance through convention alone (and the exception just alerts you that your code is obviously broken). Wrapping up the possibility of an exception that will never actually occur is just noise and boilerplate on both ends. It doesn't seem that unreasonable to sometimes trust your consumer to decide whether the additional structure is needed.

No such thing in core. But the code of defn is rather easy to follow.

True, I’ll be a little surprised if there’s not a popular macro-helper lib with such a thing, but maybe there isn’t

I think there's a clever use of spec to give you this

Oh cool, there it is: https://blog.klipse.tech/clojure/2019/03/08/spec-custom-defn.html

https://github.com/galdre/morphe is an interesting take on AOP - wrapping functions with cross cutting concerns.