4 ms·

Please elaborate more than "haha java bad"

by agilob 2y ago

otikik 2y ago
JavaBadAbstractFactoryObjectFactoryException
- Geezus_42 2y ago
  This is what I hate about supporting Java apps. Why are the errors so indecipherable and rarely well documented?
  - mike_hearn 2y ago
    Well, compared to what? The alternative to exceptions is usually worse: 1. Error codes. Try debugging Win32 software and have fun working out with all those HRESULTs mean, especially as every Google hit for any given code is just endless support forums with people complaining their computer is broken. 2. Panics. You get an error message no more helpful than an exception, except with no stack trace to help you figure out what's wrong. 3. Segfaults. You get nothing. Exceptions are the best form of error handling yet invented. Making programmers more helpful is hard, but exceptions have auto-generated error messages that at least tell you where the program died, how it got there, and very often the chain of problems that led to that surface level problem (a particular weakness of error codes where causal chains are often lost). They also often have JavaDocs explaining what they mean. Although it's not really a weakness of Java or exceptions per se, I think some people don't like them because lazy devs don't bother translating them into something more user friendly (especially for developer tools). There are simple patterns that fix that though. My company makes a CLI developer tool written in Java+Kotlin running on the JVM (see bio) and it defines a dedicated UserError exception type. If an exception bubbles to the top level of the program and it descends from UserError then it's formatted nicely with colors and shown as you'd expect. If it's not then the exception is logged and a crash reporter is started, the user is asked if they'd like to report the crash. The exception details are then printed without the stack trace and polished slightly ("FooBarException: abc" -> "Foo Bar: abc") which often makes the messages good enough that the user can unstick themselves. There are utility methods to catch and rethrow exceptions as user errors when the underlying messages are already good enough, and the product is careful to rethrow manually if the messages need to be improved. There are also utilities to verify that a file/directory exists and if not, throw a special subtype of UserError that yields a spelling corrector [1] The result is that if you check our homepage, you'll see at least one customer explicitly praised our error message quality! They were very happy to never see a stack trace from a developer tool, only actionable errors that tell you what to do. So exceptions can definitely yield a great UX. You just have to care and put in a bit of effort. IntelliJ is another example of a product where the exception UX is highly polished. Its exception reporter can figure out which plugin an error comes from, route error reports automatically, deduplicate errors based on the stack traces, attach files that the exception object advertises and so on. [1] https://hshell.hydraulic.dev/14.1/user-interaction/#path-assertions https://hshell.hydraulic.dev/14.1/user-interaction/#path-ass...
    - pquki4 2y ago
      Very well said. Parent says "errors so indecipherable and rarely well documented", when in fact Java is the better if not one of the best out there.
    - whstl 2y ago
      Sure, but GP was criticizing Java, not Exceptions. I find that JavaScript, Ruby and C# are all easier to debut in practice than Java, and all three use exceptions. IMO this is mainly due to what idiomatic Java looks like and how libraries/frameworks are structured.
      - mike_hearn 2y ago
        Hm, we've had different experiences then. My experience with languages like JS/Ruby is that exceptions are often obfuscated (for js) and will frequently be meaningless type errors like "foo is not an object". I didn't use C# but I'd guess it's similar to Java. After all, here's an exception factory library for C# (https://github.com/scionwest/ExceptionFactory https://github.com/scionwest/ExceptionFactory). What most people seem to complain about when they say "Java" is actually dependency injection frameworks, not the language or even regular libraries (which typically don't use them). I also don't like Guice so can sympathise, but DI frameworks vary in quality a lot, and you don't have to abuse them. Modern frameworks are based on code generation and check much more at compile time. My app uses a compile time DI framework to set up the build task graph, but doesn't have a factory bean anywhere and has never yielded strange errors about factories that were hard to debug.
        whstl 2y ago
        > What most people seem to complain about when they say "Java" is actually dependency injection frameworks This is precisely what I said with “ due to what idiomatic Java looks like and how libraries/frameworks are structured”. Sure, in a platonic ideal Java codebase, it’s all great, but I am talking about my actual practical experience, and I said as much in my message.
        2y ago
  - agilob 2y ago
    So in the context of a class name `JavaBadAbstractFactoryObjectFactoryException` your problem is on a human side, your colleague using bad class and var names. Language has nothing to do with it. Ruby and C# also have VERY long class names, yet we don't talk about them so much.
  - kaba0 2y ago
    Java’s errors are amongst the best in my experience. Do you prefer Python’s much more esoteric stack traces, or Go’s one liner zero information spam, or the traditional “SegFault”? Like honestly, which ecosystem has better exceptions/error messages, in the general case? Java pinpoints the exact source of the error with useful context. It’s as good as it can get.
- The_Colonel 2y ago
  So just "haha Java bad".
  - otikik 2y ago
    I did expand. If he wanted more, he should have assembled a better set of requirements.
- deely3 2y ago
  Did we started judging language by some libraries written in that language? Also, where did you encounter this exception? Im really curious.
agency 2y ago
I was a Java apologist for a long time and I still think you can write fine software in it (and the JVM is an incredible piece of engineering). But the fact that the class is the _only_ unit of abstraction is just so frustrating to me now (Yegge's Execution in the Kingdom of Nouns makes this criticism in a humorous allegory[1]). Modern Java does mitigate this somewhat. Lambdas provide nice sugar over the inline class-creation you'd have to do of yore. Records make it less of a pain to define POJOs. But I think this fundamental issue is at the root of much of the language's clunkiness. [1] http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html?m=1 http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
- neonsunset 2y ago
  They were close but unfortunately went too far at being opinionated in solve the issues of using C at the time of Java's inception. Changing this now is Valhalla project which has unknown release date. Luckily, C# learned from this mistake and made a decision to follow C much closely, having integers as proper primitives and supporting structs since day 1, and only improved since then in this area (JVM needs insane pointer compression and shadow tricks to pack integers to claw back performance, and in .NET "it just works" instead). I wonder if Cassandra was written in .NET, it wouldn't have such a poor performance (though this can also be showcased by Garnet which beats competition written in C++ and C).
- mudhad 2y ago
  class, interface, record, SAMs (for lamdas). Value types are in the works, and would bring it to a similar level to C# or C++.

Please elaborate more than "haha java bad"

by agilob 2y ago

Please elaborate more than "haha java bad"

otikik 2y ago

JavaBadAbstractFactoryObjectFactoryException

Geezus_42 2y ago
This is what I hate about supporting Java apps. Why are the errors so indecipherable and rarely well documented?
- mike_hearn 2y ago
  Well, compared to what? The alternative to exceptions is usually worse: 1. Error codes. Try debugging Win32 software and have fun working out with all those HRESULTs mean, especially as every Google hit for any given code is just endless support forums with people complaining their computer is broken. 2. Panics. You get an error message no more helpful than an exception, except with no stack trace to help you figure out what's wrong. 3. Segfaults. You get nothing. Exceptions are the best form of error handling yet invented. Making programmers more helpful is hard, but exceptions have auto-generated error messages that at least tell you where the program died, how it got there, and very often the chain of problems that led to that surface level problem (a particular weakness of error codes where causal chains are often lost). They also often have JavaDocs explaining what they mean. Although it's not really a weakness of Java or exceptions per se, I think some people don't like them because lazy devs don't bother translating them into something more user friendly (especially for developer tools). There are simple patterns that fix that though. My company makes a CLI developer tool written in Java+Kotlin running on the JVM (see bio) and it defines a dedicated UserError exception type. If an exception bubbles to the top level of the program and it descends from UserError then it's formatted nicely with colors and shown as you'd expect. If it's not then the exception is logged and a crash reporter is started, the user is asked if they'd like to report the crash. The exception details are then printed without the stack trace and polished slightly ("FooBarException: abc" -> "Foo Bar: abc") which often makes the messages good enough that the user can unstick themselves. There are utility methods to catch and rethrow exceptions as user errors when the underlying messages are already good enough, and the product is careful to rethrow manually if the messages need to be improved. There are also utilities to verify that a file/directory exists and if not, throw a special subtype of UserError that yields a spelling corrector [1] The result is that if you check our homepage, you'll see at least one customer explicitly praised our error message quality! They were very happy to never see a stack trace from a developer tool, only actionable errors that tell you what to do. So exceptions can definitely yield a great UX. You just have to care and put in a bit of effort. IntelliJ is another example of a product where the exception UX is highly polished. Its exception reporter can figure out which plugin an error comes from, route error reports automatically, deduplicate errors based on the stack traces, attach files that the exception object advertises and so on. [1] https://hshell.hydraulic.dev/14.1/user-interaction/#path-assertions https://hshell.hydraulic.dev/14.1/user-interaction/#path-ass...
  - pquki4 2y ago
    Very well said. Parent says "errors so indecipherable and rarely well documented", when in fact Java is the better if not one of the best out there.
  - whstl 2y ago
    Sure, but GP was criticizing Java, not Exceptions. I find that JavaScript, Ruby and C# are all easier to debut in practice than Java, and all three use exceptions. IMO this is mainly due to what idiomatic Java looks like and how libraries/frameworks are structured.
    - mike_hearn 2y ago
      Hm, we've had different experiences then. My experience with languages like JS/Ruby is that exceptions are often obfuscated (for js) and will frequently be meaningless type errors like "foo is not an object". I didn't use C# but I'd guess it's similar to Java. After all, here's an exception factory library for C# (https://github.com/scionwest/ExceptionFactory https://github.com/scionwest/ExceptionFactory). What most people seem to complain about when they say "Java" is actually dependency injection frameworks, not the language or even regular libraries (which typically don't use them). I also don't like Guice so can sympathise, but DI frameworks vary in quality a lot, and you don't have to abuse them. Modern frameworks are based on code generation and check much more at compile time. My app uses a compile time DI framework to set up the build task graph, but doesn't have a factory bean anywhere and has never yielded strange errors about factories that were hard to debug.
      - whstl 2y ago
        > What most people seem to complain about when they say "Java" is actually dependency injection frameworks This is precisely what I said with “ due to what idiomatic Java looks like and how libraries/frameworks are structured”. Sure, in a platonic ideal Java codebase, it’s all great, but I am talking about my actual practical experience, and I said as much in my message.
        2y ago
- agilob 2y ago
  So in the context of a class name `JavaBadAbstractFactoryObjectFactoryException` your problem is on a human side, your colleague using bad class and var names. Language has nothing to do with it. Ruby and C# also have VERY long class names, yet we don't talk about them so much.
- kaba0 2y ago
  Java’s errors are amongst the best in my experience. Do you prefer Python’s much more esoteric stack traces, or Go’s one liner zero information spam, or the traditional “SegFault”? Like honestly, which ecosystem has better exceptions/error messages, in the general case? Java pinpoints the exact source of the error with useful context. It’s as good as it can get.
The_Colonel 2y ago
So just "haha Java bad".
- otikik 2y ago
  I did expand. If he wanted more, he should have assembled a better set of requirements.
deely3 2y ago
Did we started judging language by some libraries written in that language? Also, where did you encounter this exception? Im really curious.

agency 2y ago

I was a Java apologist for a long time and I still think you can write fine software in it (and the JVM is an incredible piece of engineering). But the fact that the class is the _only_ unit of abstraction is just so frustrating to me now (Yegge's Execution in the Kingdom of Nouns makes this criticism in a humorous allegory[1]). Modern Java does mitigate this somewhat. Lambdas provide nice sugar over the inline class-creation you'd have to do of yore. Records make it less of a pain to define POJOs. But I think this fundamental issue is at the root of much of the language's clunkiness. [1] http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html?m=1 http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

neonsunset 2y ago
They were close but unfortunately went too far at being opinionated in solve the issues of using C at the time of Java's inception. Changing this now is Valhalla project which has unknown release date. Luckily, C# learned from this mistake and made a decision to follow C much closely, having integers as proper primitives and supporting structs since day 1, and only improved since then in this area (JVM needs insane pointer compression and shadow tricks to pack integers to claw back performance, and in .NET "it just works" instead). I wonder if Cassandra was written in .NET, it wouldn't have such a poor performance (though this can also be showcased by Garnet which beats competition written in C++ and C).
mudhad 2y ago
class, interface, record, SAMs (for lamdas). Value types are in the works, and would bring it to a similar level to C# or C++.