5 ms·

I stopped using Java a long time ago, and so I assume the language has gotten better since then, but early on at least it felt like Java almost took pride in ma

I stopped using Java a long time ago, and so I assume the language has gotten better since then, but early on at least it felt like Java almost took pride in making the developer jump through extra hoops. Compared to many other languages, using Java just made me feel tired. Checked exceptions - a feature that seems to be a cost to the developer 100% of the time while being a benefit far less than 1% of the time - is a quintessential example of Java's tendency to cause developer fatigue.

naasking 3y ago
> Checked exceptions - a feature that seems to be a cost to the developer 100% of the time That's because exceptions are overused for not-truly-exceptional conditions. Languages that throw exceptions when a dictionary does not have a key you're looking for are doing it wrong.
narag 3y ago
Java almost took pride in making the developer jump through extra hoops That's exactly it. A holier-than-thou stance, reprised by most comments in this post. Checked exceptions were a PITA. Someone has recommended to use another language if you didn't like it. Unfortunately my employer at that time had entered a partnership with Sun that prevented that :) Another ideological prohibition: no pointers. Well, how do you assign event handlers then? People were extremely confused with anonymous classes. I got the reason instantly.
breadwinner 3y ago
Some people say the same about strong typing. Like, why do I have to write down the type of every single parameter or variable? Java is making me jump through hoops! The point is, if you don't need the rigor of a strongly typed compiled language, there are other languages you can use. Perhaps a bash script is all you need.
- dbrueck 3y ago
  > The point is, if you don't need the rigor of a strongly typed compiled language This has nothing to do with strongly typed compiled languages vs alternatives.
- wiseowise 3y ago
  Java is the only mainstream language with checked exceptions and checked exceptions are nowhere near usefulness of static typing. Following your logic, Java developers can now say “if you don’t like freedom of Java, use Rust/Haskell/Scala to validate everything at compile time”
  - lostmsu 3y ago
    You could say Rust error handling is more like checked than unchecked exceptions.
    - wiseowise 3y ago
      It is, that’s the whole point.
  - treis 3y ago
    Checked exceptions are part and parcel of a type system, though. If you have a foo function that returns a value or error you've got different options. Pseudo code they are: foo():boolean throws Some, List, Of, Errors foo():boolean | Some | List | Of | Errors foo():(boolean | nil) , (nil | Some | List | Of | Errors) The first is checked exceptions. The second is returning different types. Typically there's some sort of Option wrapper for ergonomics. The third returns a result, err tuple and by checking if err is nil you can see if foo succeeded. Ultimately they are all the same. What differs is the boilerplate/syntax to accomplish what you want. If what you want is a generic error to handle unknown events then you gotta write it that way no matter which system you use.
  - crabbone 3y ago
    Java is not the only language that has checked exceptions. C++ has them too, for example, but thanks god virtually nobody uses them in C++.
    - nemetroid 3y ago
      Checked exceptions (i.e. "dynamic exception specification") were deprecated in C++11 and removed in C++17.
- ablob 3y ago
  In strong typing you don't have to (See type inference). It just means that the shape of the data/object you receive is known to you. That a lot of languages force you to write it out is not an inherent property of strong typing.
- gjvc 3y ago
  Perhaps a bash script is all you need. Brutal, even for this site
- crabbone 3y ago
  You are very confused... "strong" in strong typing doesn't mean you have to write much or at all. Actually, it doesn't mean anything really. But, let's say, Haskell is probably at least as "strongly typed" as Java -- at least that's how most people understand that wording. And you don't have to write types in Haskell at all. It will be a nightmare (as if Haskell can be anything else, but even by the very low Haskell standards, it would still be a nightmare) code, but it will "work". Until very recently, Java was just tedious, repetitive, high-entropy language, where you had to write everything multiple times. Eg.: VeryLong<Type> variable = VeryLong<Type>(); In this expression, it's obvious what would be the most likely type of variable, but you still have to write it twice -- which is just worthless use of your time, especially when trying to read this very repetitive mess, and very easy to make a typo. Recently, Java tried to improve this situation by allowing to omit types when the type inferred by default is the one you want. So, you need to write less. You also need to learn the inference rules, obviously, so it increases the cognitive load and rises expectations towards programmer's skill a bit. But, I think it's fair, since Java from a language for the brain-dead transformed into a language that requires more effort to master. While I'm not sure it's a positive change... this decision by Java developers kind of flies in the face of your argument: No, it's not necessary to repeatedly spell out what you want your program to do. It's just boring and contributes nothing to the program's correctness. If anything, it only causes the programmer to lose focus and introduces mechanical errors that would've been totally avoidable, had the language was more terse.
  - vips7L 3y ago
    > Until very recently, Java was just tedious, repetitive, high-entropy language, where you had to write everything multiple times. More than half a decade ago.
    - esafak 3y ago
      Which means today's code.
  - breadwinner 3y ago
    Type inferencing can get you in trouble quickly. Consider this code: var fireable = someMethod(); firable.fire(); The programmer intended this code to fire an employee. Let's say this code is in a military application, and another programmer modified the someMethod() function to return a missile. As long as the missile object has a fire() method this code will compile just fine... and do something the code didn't intend to do. How likely are you to have employee firing and missile firing in the same program? Not very likely, but the principle is valid, regardless. You need to express your intention more clearly like this: Employee fireable = someMethod(); Now if someMethod() is modified to return a missile you get a compilation error, and the world will be a lot safer. You don't want missiles being fired by accident!
- ok123456 3y ago
  If checked exceptions were implemented in such a way that they were inferred, and they weren't erased in the byte code, much like how people use strong types now, they wouldn't be seen as hoops. Meaning, if you didn't explicitly handle a checked exception, it would automatically bubble up yet be visible to your IDE. I would love if, at design time, all the possible exceptions that could happen were able to be inferred. But, the way it happens in java, it's entirely manual, and it won't catch things where I'm referencing compiled code. The design of checked exceptions in Java lead to all kinds of exception anti-patterns becoming common, just to shut up javac.
  - LorenPechtel 3y ago
    Exactly. I have no problem with a function declaring the sort of exceptions it can handle, although simply handling them when they occur is normally good enough.

naasking 3y ago

> Checked exceptions - a feature that seems to be a cost to the developer 100% of the time That's because exceptions are overused for not-truly-exceptional conditions. Languages that throw exceptions when a dictionary does not have a key you're looking for are doing it wrong.

narag 3y ago

Java almost took pride in making the developer jump through extra hoops That's exactly it. A holier-than-thou stance, reprised by most comments in this post. Checked exceptions were a PITA. Someone has recommended to use another language if you didn't like it. Unfortunately my employer at that time had entered a partnership with Sun that prevented that :) Another ideological prohibition: no pointers. Well, how do you assign event handlers then? People were extremely confused with anonymous classes. I got the reason instantly.

breadwinner 3y ago

Some people say the same about strong typing. Like, why do I have to write down the type of every single parameter or variable? Java is making me jump through hoops! The point is, if you don't need the rigor of a strongly typed compiled language, there are other languages you can use. Perhaps a bash script is all you need.

dbrueck 3y ago
> The point is, if you don't need the rigor of a strongly typed compiled language This has nothing to do with strongly typed compiled languages vs alternatives.
wiseowise 3y ago
Java is the only mainstream language with checked exceptions and checked exceptions are nowhere near usefulness of static typing. Following your logic, Java developers can now say “if you don’t like freedom of Java, use Rust/Haskell/Scala to validate everything at compile time”
- lostmsu 3y ago
  You could say Rust error handling is more like checked than unchecked exceptions.
  - wiseowise 3y ago
    It is, that’s the whole point.
- treis 3y ago
  Checked exceptions are part and parcel of a type system, though. If you have a foo function that returns a value or error you've got different options. Pseudo code they are: foo():boolean throws Some, List, Of, Errors foo():boolean | Some | List | Of | Errors foo():(boolean | nil) , (nil | Some | List | Of | Errors) The first is checked exceptions. The second is returning different types. Typically there's some sort of Option wrapper for ergonomics. The third returns a result, err tuple and by checking if err is nil you can see if foo succeeded. Ultimately they are all the same. What differs is the boilerplate/syntax to accomplish what you want. If what you want is a generic error to handle unknown events then you gotta write it that way no matter which system you use.
- crabbone 3y ago
  Java is not the only language that has checked exceptions. C++ has them too, for example, but thanks god virtually nobody uses them in C++.
  - nemetroid 3y ago
    Checked exceptions (i.e. "dynamic exception specification") were deprecated in C++11 and removed in C++17.
ablob 3y ago
In strong typing you don't have to (See type inference). It just means that the shape of the data/object you receive is known to you. That a lot of languages force you to write it out is not an inherent property of strong typing.
gjvc 3y ago
Perhaps a bash script is all you need. Brutal, even for this site
crabbone 3y ago
You are very confused... "strong" in strong typing doesn't mean you have to write much or at all. Actually, it doesn't mean anything really. But, let's say, Haskell is probably at least as "strongly typed" as Java -- at least that's how most people understand that wording. And you don't have to write types in Haskell at all. It will be a nightmare (as if Haskell can be anything else, but even by the very low Haskell standards, it would still be a nightmare) code, but it will "work". Until very recently, Java was just tedious, repetitive, high-entropy language, where you had to write everything multiple times. Eg.: VeryLong<Type> variable = VeryLong<Type>(); In this expression, it's obvious what would be the most likely type of variable, but you still have to write it twice -- which is just worthless use of your time, especially when trying to read this very repetitive mess, and very easy to make a typo. Recently, Java tried to improve this situation by allowing to omit types when the type inferred by default is the one you want. So, you need to write less. You also need to learn the inference rules, obviously, so it increases the cognitive load and rises expectations towards programmer's skill a bit. But, I think it's fair, since Java from a language for the brain-dead transformed into a language that requires more effort to master. While I'm not sure it's a positive change... this decision by Java developers kind of flies in the face of your argument: No, it's not necessary to repeatedly spell out what you want your program to do. It's just boring and contributes nothing to the program's correctness. If anything, it only causes the programmer to lose focus and introduces mechanical errors that would've been totally avoidable, had the language was more terse.
- vips7L 3y ago
  > Until very recently, Java was just tedious, repetitive, high-entropy language, where you had to write everything multiple times. More than half a decade ago.
  - esafak 3y ago
    Which means today's code.
- breadwinner 3y ago
  Type inferencing can get you in trouble quickly. Consider this code: var fireable = someMethod(); firable.fire(); The programmer intended this code to fire an employee. Let's say this code is in a military application, and another programmer modified the someMethod() function to return a missile. As long as the missile object has a fire() method this code will compile just fine... and do something the code didn't intend to do. How likely are you to have employee firing and missile firing in the same program? Not very likely, but the principle is valid, regardless. You need to express your intention more clearly like this: Employee fireable = someMethod(); Now if someMethod() is modified to return a missile you get a compilation error, and the world will be a lot safer. You don't want missiles being fired by accident!
ok123456 3y ago
If checked exceptions were implemented in such a way that they were inferred, and they weren't erased in the byte code, much like how people use strong types now, they wouldn't be seen as hoops. Meaning, if you didn't explicitly handle a checked exception, it would automatically bubble up yet be visible to your IDE. I would love if, at design time, all the possible exceptions that could happen were able to be inferred. But, the way it happens in java, it's entirely manual, and it won't catch things where I'm referencing compiled code. The design of checked exceptions in Java lead to all kinds of exception anti-patterns becoming common, just to shut up javac.
- LorenPechtel 3y ago
  Exactly. I have no problem with a function declaring the sort of exceptions it can handle, although simply handling them when they occur is normally good enough.