5 ms·

Exceptions are not a part of your method signature, so every time you call something you don't know if you have to catch an exception or not. Java tried to fix

Exceptions are not a part of your method signature, so every time you call something you don't know if you have to catch an exception or not. Java tried to fix that, but doesn't let you generalize over exceptions, "my method throws FooException and whatever exceptions method Bar on the instance of Glorbable you're passing me throws". Nulls have the same problem. Every time you get an instance of Foo you don't know if it's a null or an object. C# is trying to migrate to explicit nullability, but it's hard to convert an established ecosystem with idiosyncratic nullability rules.

brabel 6y ago
> ... but it's hard to convert an established ecosystem with idiosyncratic nullability rules. Dart has just done that, though admitedly, it did not have an ecosystem as large as C#'s.
- orthoxerox 6y ago
  C# had to invent attributes to work around structs vs classes and around TryX methods where out variables are null or not based on the return value. And the issue of arrays of objects or objects inside structs hasn't been resolved yet.
wvenable 6y ago
Assume all methods can throw exceptions. And if, by chance, you believe a method doesn't throw an exception today you have no idea if it's implementation will change tomorrow and it will then throw an exception. Whether a method throws an exception or not doesn't matter as much as people think it does. You can rarely recover from an exception in the immediate parent calling method anyway. More than likely the error will occur in a stack 20 layers deep and recovery is to restart the entire operation from the start. Nulls are useful but I totally agree that they should be opt-in in the type system.
pjmlp 6y ago
> Java tried to fix that Nope, Java picked the idea from CLU, Modual-3 and C++, in what seemed the way forward to declare exceptions. It does provide both checked and unckecked exceptions, unfortunely it suffers from bad learnings and quick hacks to shut the compiler instead of thinking it through when designing class libraries (yes even the std suffers from this).

brabel 6y ago

> ... but it's hard to convert an established ecosystem with idiosyncratic nullability rules. Dart has just done that, though admitedly, it did not have an ecosystem as large as C#'s.

orthoxerox 6y ago
C# had to invent attributes to work around structs vs classes and around TryX methods where out variables are null or not based on the return value. And the issue of arrays of objects or objects inside structs hasn't been resolved yet.

wvenable 6y ago

Assume all methods can throw exceptions. And if, by chance, you believe a method doesn't throw an exception today you have no idea if it's implementation will change tomorrow and it will then throw an exception. Whether a method throws an exception or not doesn't matter as much as people think it does. You can rarely recover from an exception in the immediate parent calling method anyway. More than likely the error will occur in a stack 20 layers deep and recovery is to restart the entire operation from the start. Nulls are useful but I totally agree that they should be opt-in in the type system.

pjmlp 6y ago

> Java tried to fix that Nope, Java picked the idea from CLU, Modual-3 and C++, in what seemed the way forward to declare exceptions. It does provide both checked and unckecked exceptions, unfortunely it suffers from bad learnings and quick hacks to shut the compiler instead of thinking it through when designing class libraries (yes even the std suffers from this).