4 ms·

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.

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.