i) There's RuntimeException which is an unchecked exception which could happen anywhere, so even the absence of a throws is not a guarantee of not throwing.
ii) In order to avoid many different throws specifiers, you end up with wrapping exceptions to a smaller set of exceptions (e.g. JNDI may throw a NamingException that wraps an IOException)
iii) IDEs offer to put try-catch { // todo } to avoid compiler errors. Developers often stop thinking then, where the right thing is more often to let it throw - e.g. I've seen FileNotFound being caught and logged (at debug) and not exposed to a caller, so a UI doesn't see it, with bad results.
I think it was the ZX81 (and later the Spectrum) where my brother and I had it hooked up to the mains on my parent's boat. The problem was there was only one 12V battery (via a voltage regulator) which not only powered lights and our computer, but also served the engine. If we were sailing and the wind dropped, we established a protocol where my Dad would have to give sufficient notice for us to save whatever we were working on to tape before he started the engine, as the starter motor drew enough current to dip the voltage below the 9V the ZX81 needed, thus causing it to crash. And of course, RAM wobble wasn't helped if there were heavy waves. It's amazing what we put up with just to get some computing time.
from:
Where the first does one request and doesn't start the next until the previous had completed, and the second does them concurrently.
BUT - you could have a language where async functions are awaited by default, and you'd have to write something like:
Where pending means don't await, and absence of it when invoking an async function does require it.
Presence of an 'async' decorator on functions isn't strictly needed, but does convey extra information in the API, which is useful.