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.
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.
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.
which effectively looks up error codes in Windows SDK header files (which need not be installed)
~> err 0x80070091
# No results found for hex 0x80070091 / decimal -2147024751
# as an HRESULT: Severity: FAILURE (1), FACILITY_WIN32 (0x7), Code 0x91
# for hex 0x91 / decimal 145
ERROR_DIR_NOT_EMPTY winerror.h
# The directory is not empty.
# 1 matches found for "0x80070091"
~> err 91
# for decimal 91 / hex 0x5b
SET_ENV_VAR_FAILED bugcodes.h
NMERR_DISCARD_FRAME netmon.h
LDAP_CONNECT_ERROR winldap.h
# for hex 0x91 / decimal 145
WIN32K_INIT_OR_RIT_FAILURE bugcodes.h
ERROR_DIR_NOT_EMPTY winerror.h
# The directory is not empty.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x91
# for hex 0x91 / decimal 145
ERROR_DIR_NOT_EMPTY winerror.h
# The directory is not empty.
# 6 matches found for "91"
which is frequently better than nothing, grep, or Google, especially for small integer error codes (and, in the case of Google, for any HRESULT Windows Update or the Microsoft Store has ever returned).
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.
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).
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.
Yeah but I don't know if DI (ab)usage is really idiomatic Java. I've written lots of Java over the years and only rarely used DI frameworks. Libraries never use them. When I did use them they've been fairly restrained and most of the code you wouldn't notice it. It might be idiomatic if all you do is write web servers.
