Checked vs unchecked exceptions

Sebastien Alaiwan via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 27 09:54:08 PDT 2017


On Tuesday, 27 June 2017 at 10:18:04 UTC, mckoder wrote:
> "I think that the belief that everything needs strong static 
> (compile-time) checking is an illusion; it seems like it will 
> buy you more than it actually does. But this is a hard thing to 
> see if you are coming from a statically-typed language."
>
> Source: 
> https://groups.google.com/forum/#!original/comp.lang.java.advocacy/r8VPk4deYDI/qqhL8g1uvf8J
>
> If you like dynamic languages such as Python you probably agree 
> with Bruce Eckel. If you are a fan of static checking then I 
> don't see how you can like that.

A quote from Uncle Bob about too much static typing and checked 
exceptions:

http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html

"My problem is that [Kotlin and Swift] have doubled down on 
strong static typing. Both seem to be intent on closing every 
single type hole in their parent languages."

"I would not call Java a strongly opinionated language when it 
comes to static typing. You can create structures in Java that 
follow the type rules nicely; but you can also violate many of 
the type rules whenever you want or need to. The language 
complains a bit when you do; and throws up a few roadblocks; but 
not so many as to be obstructionist.

Swift and Kotlin, on the other hand, are completely inflexible 
when it comes to their type rules. For example, in Swift, if you 
declare a function to throw an exception, then by God every call 
to that function, all the way up the stack, must be adorned with 
a do-try block, or a try!, or a try?. There is no way, in this 
language, to silently throw an exception all the way to the top 
level; without paving a super-hiway for it up through the entire 
calling tree."


More information about the Digitalmars-d mailing list