[mike_hearn]

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-ass...

[jasomill]

I completely agree with you, but on a side note, you can at least get descriptive text for most Microsoft-defined error codes using

https://www.microsoft.com/en-my/download/details.aspx?id=100...

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).

[pquki4]

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]

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]

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.

[whstl]

> 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.

[mike_hearn]

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.

[whstl]

Alright, that's fair! I only ever wrote web apps in Java, other than very small scripts and libraries. You're right.