4 ms·

Well RuntimeErrors (NullPointerExceptions's and the like) weren't never explicitly required to be on the method signature. I was trying to remember who it was,

by bb88 3y ago

Well RuntimeErrors (NullPointerExceptions's and the like) weren't never explicitly required to be on the method signature. I was trying to remember who it was, but one author I thought had recommended subclassing every exception as a Runtime exception for this reason.

threeseed 3y ago
Yes there are checked and unchecked exceptions. NullPointerException don't really make sense as checked because almost every method will have some exposure to null values. But the idea is that encapsulating methods can check for those and translate them into other exception types or just let it be handled by a global exception handler. Java is not the best for error handling by any stretch. But it's easily better than Go.
- free652 3y ago
  >Java is not the best for error handling by any stretch. But it's easily better than Go. Nah. If you ever worked in a big enough company you would have: try & catch Throwable at the main entry. Go forces to think about every error. C# doesn't even have checked errors, after using Java for 10 years - checked exceptions are dumb. Go doesn't have a stack trace in the error and thats dumb.
  - majormajor 3y ago
    > Go forces to think about every error. Unless you just always return it up the chain without thinking about it like the bulk of the code I've encountered. No more thoughtful than "catch and reraise" or "just throw." And like in Java, an NPE ain't getting caught by the error return of a function in Go either.
    - masklinn 3y ago
      Even if you ignore this, assume nobody ever created an editor macro to smash, go has several glaring holes which make it very possible (and reasonably easy) to miss errors entirely. And unlike Java, those errors are just gone, they won’t be breaking noisily eventually.
  - threeseed 3y ago
    Not sure what you mean there. With checked exceptions you need to either handle them directly or yes you can wrap them in a RuntimeException and catch it in main. I've done a decade of old-school JVM development at enterprise companies. Never seen any codebase where no exceptions are locally handed.
  - pjmlp 3y ago
    Until your beloved C# application crashes in production on black friday, because you forgot to catch an exception.

by bb88 3y ago

threeseed 3y ago

Yes there are checked and unchecked exceptions. NullPointerException don't really make sense as checked because almost every method will have some exposure to null values. But the idea is that encapsulating methods can check for those and translate them into other exception types or just let it be handled by a global exception handler. Java is not the best for error handling by any stretch. But it's easily better than Go.

free652 3y ago
>Java is not the best for error handling by any stretch. But it's easily better than Go. Nah. If you ever worked in a big enough company you would have: try & catch Throwable at the main entry. Go forces to think about every error. C# doesn't even have checked errors, after using Java for 10 years - checked exceptions are dumb. Go doesn't have a stack trace in the error and thats dumb.
- majormajor 3y ago
  > Go forces to think about every error. Unless you just always return it up the chain without thinking about it like the bulk of the code I've encountered. No more thoughtful than "catch and reraise" or "just throw." And like in Java, an NPE ain't getting caught by the error return of a function in Go either.
  - masklinn 3y ago
    Even if you ignore this, assume nobody ever created an editor macro to smash, go has several glaring holes which make it very possible (and reasonably easy) to miss errors entirely. And unlike Java, those errors are just gone, they won’t be breaking noisily eventually.
- threeseed 3y ago
  Not sure what you mean there. With checked exceptions you need to either handle them directly or yes you can wrap them in a RuntimeException and catch it in main. I've done a decade of old-school JVM development at enterprise companies. Never seen any codebase where no exceptions are locally handed.
- pjmlp 3y ago
  Until your beloved C# application crashes in production on black friday, because you forgot to catch an exception.