Your first Scala example uses Int, which isn't nullable in Scala. You probably want to change that to String or something else that could actually be null. It also uses the deprecated "procedure" syntax so you might want to put an = in there or ": Unit =" to be explicit about the return type.

It seems to me that you are taking on two different things here. null vs. Option is really a question of how you should represent a value that doesn't exist. I don't think there is much debate there. Using null to represent values that don't exist is highly error prone and should be avoided. Note that newer languages are going even further to remove null or to add syntax for handling it. Scala 3 has an option for null-safety that pulls the Null type out from under AnyRef so that you can't have things like a null String. Kotlin and Rust are other examples.

Error handling is a much bigger topic. Exceptions seemed like a great idea but they haven't panned out the way that people thought they would. They have negatives, which you highlight. Using types to indicate errors is a much better way to go. You mention the various ways of doing that in Scala. These have evolved over time. This is an area where Rust simplified things and did away with exceptions all together.

I haven't thought much about this, but I could imagine a future version of Scala, after another round of breaking changes, that basically eliminated exceptions in their current form. For backward compatibility it treats any function that would throw an exception as having a Try return type or something like that. I'm not certain that is even possible, but it seems like an interesting idea to explore.