The imported files should really hurl their exported functions, and the importer needs to catch it into a variable.

That’s a great idea. I’ll have to do that for the next version.

Oh, dependency injection?

Maybe even dependency ejection.

Ha!

> I mean, it’s a language based around exceptions for flow control, I think the “easy to reason about” ship has sailed.

Sometimes I wonder if I'm exceptionally (haha) talented as I personally find the impact of exceptions on flow control pretty easy to grasp. But based on my understanding of other advanced computer language concepts, which is pretty lacking in some regards, I come to the conclusion that it can't be too hard, and people make a lot of fuss about it for no particular reason.

It’s largely difficult because either:

- you’re working in a language that doesn’t have checked exceptions, so the set of potential errors and the set of potentially error-raising calls is infinite but unknowable

- you’re working in a language that has checked exceptions, and you hate that it makes you do work, so you catch-rethrow runtime errors that recreate the first scenario

- you’re working in a language that has checked exceptions, but someone else did the second scenario so you’re in the first scenario anyway

Other programmers tend to be bad at reliably cleaning up resources such as file handles, locks etc, so I need to inspect the whole invocation tree anyways to have an understanding of what runtime implications I've summoned by invoking other people's code.

As for myself, I've lived through the hell that are checked exceptions in Java. You learn that compositionality and checked exceptions are at odds when you try to insert a remoting layer into an application that has grown without IOExceptions. Then you learn that it's actually not necessary to know the set of possible errors, just make sure that you're not a bad programmer as in my first paragraph, and everyone will be fine. This is also something that you can learn from Exceptional C++.

Yeah, I’ve never understood the complaints about exceptions either: most of the time you want the exceptions to just bubble up anyway because, in that case, you only have to think about the contracts of the functions you interact with and not about the unusual states you might be in. Return-type or return-value based error handling has always seemed to me to be significantly worse.

The unchecked exception example doesn't seem any different than using a dynamically typed language and reading return values, and exceptions seem to get significantly more hate than those.

Because even in a dynamically typed language you can generally go look at what the function returns. You can’t look at what it throws without walking the entire call stack and inspecting the source code of the runtime.

Flow control involving recursion is already well into the weeds. Recursion and exceptions is probably a nightmare for someone not fond of ML or Lisp.

But why? I don't get it. You call something. It can break. It will break. Treat it as such wrt to resources you've allocated. You can ignore error details here.

At the highest level of your application (and at a few critical places, executors, retrying strategies etc) handle all the exceptions you know of, and implement a sane default for everything you don't know.

Done.

Not really, what’s happened is that everyone’s so scared of exceptions they only use them in extremely confined ways. These ways are relatively easy to reason about. But the full fat arbitrary goto around your call stack is avoided.

I agree, side-effecting imports add to the spooky action at a distance aesthetic.

i think you mean to to say "has sunk"