7 ms·

I agree with his premise that exceptions get misused by "average" developers. Where I work I see a lot of swallowed exception, which has lead to some evil bugs.

I agree with his premise that exceptions get misused by "average" developers. Where I work I see a lot of swallowed exception, which has lead to some evil bugs. I have also encountered some code that's literally impossible to write meaningful test code for because every exception is swallowed and there's no return code. However, I don't think that going back to checking return codes solves anything. Most of the problems I see at work are related more to checked exceptions than using exceptions in general. Thankfully, most of java frameworks I use have moved towards making everything an unchecked exception.

jrockway 18y ago
I only write Java on very rare occasions (usually for clients that don't care if the code is throw-away quality), and so I usually end up with a "throws Exception" after every method. Horrible, but hey... it's not my fault Java sucks so hard.
- ajross 18y ago
  No offense, but yeah: that's pretty horrible. Checked exceptions are one of Java's few true innovations. Used properly, they force you to handle errors in the spots where they occur. What you're doing is a 1:1 equivalent of ignoring the error codes returned from your C functions. That's just never the right way to do thing.
  - olavk 18y ago
    Propagating exceptions without handling them anywhere is bad, but IMHO still better than ignoring an error code. If you ignore an error code, the program will continue but probably fail later or just be wrong in subtle ways, generate corrupt output or whatever. An unhanded exception OTOH will just stop the program. At least then you realize you have a problem, and where it originated. Empty catch-clauses however, are just as bad as ignoring an error code.
  - narag 18y ago
    A good thing about exceptions is that you can place your handler where you know it's best, that could be in the top level. Unless you use Java so you are forced to fill this burocratic method passport all along the way. That's no good and putting the word "innovation" there freaks me.
  - wvenable 18y ago
    Exceptions are not meant to be handled where they occur, that's why they unroll the stack. For the most part, you can't recover from an exception -- you just abort whatever you're doing, print an error message, and let the user try something else. Checked exceptions cause developers to re-interpret the exceptions or just swallow them -- neither is a benefit.
    - jrockway 18y ago
      Exactly. If the database server blew up, there's nothing my program can do. I could try reconnecting, and some libraries do, but that doesn't usually help anything. Once the server is back up, the Fibonacci (or exponential) back-off is so high that's it's faster to just restart the program manually. So usually, dying is easier for everyone.
  - wallflower 18y ago
    On a large CRM-type application I worked on in the past, database constraints were used to enforce stuff like unique login IDs. Yes, some validation could be done in the UI but that was the way it was done. When a user tries to create a user with a login ID that already existed, the database constraint is encountered and an Oracle exception is thrown. It is caught and and packaged up through the application stack until it becomes an application-level exception. The end user sees a localized, friendly message instead of seeing a raw, nasty ORA error message. I'm not sure how this could be done without checked exceptions.
    - arockwell 18y ago
      You can use unchecked exceptions exactly the same way with as checked exceptions. The difference is that you can ignore them and let them propagate up when it makes sense. A real-world example of your use case: The Spring framework repackages all SQLExceptions into a custom data access exception hierarchy. So, if you choose, you could catch a DatabaseConstraintException (or whatever the appropriate exception is, I'm not sure off the top of my head), and throw an application specific exception like InvalidLoginId.
      - wallflower 18y ago
        Thanks. That's cheating, you can't use magic :) We use Spring in our current app and I don't know how it does the cross-cutting it does; it just does.
- arockwell 18y ago
  That's pretty ugly, although I've seen a lot of that style of coding at my workplace as well. The problem is that there generally isn't anything useful to do once you catch the exception besides throw up an error page. You're probably bother off either throwing RuntimeExceptions or wrapping exceptions as RuntimeExceptions.
ricky_clarkson 18y ago
There are other return codes besides ints. E.g., replace a function that returns an int or throws an IOException with one that returns an Either<int, IOException>.

jrockway 18y ago

I only write Java on very rare occasions (usually for clients that don't care if the code is throw-away quality), and so I usually end up with a "throws Exception" after every method. Horrible, but hey... it's not my fault Java sucks so hard.

ajross 18y ago
No offense, but yeah: that's pretty horrible. Checked exceptions are one of Java's few true innovations. Used properly, they force you to handle errors in the spots where they occur. What you're doing is a 1:1 equivalent of ignoring the error codes returned from your C functions. That's just never the right way to do thing.
- olavk 18y ago
  Propagating exceptions without handling them anywhere is bad, but IMHO still better than ignoring an error code. If you ignore an error code, the program will continue but probably fail later or just be wrong in subtle ways, generate corrupt output or whatever. An unhanded exception OTOH will just stop the program. At least then you realize you have a problem, and where it originated. Empty catch-clauses however, are just as bad as ignoring an error code.
- narag 18y ago
  A good thing about exceptions is that you can place your handler where you know it's best, that could be in the top level. Unless you use Java so you are forced to fill this burocratic method passport all along the way. That's no good and putting the word "innovation" there freaks me.
- wvenable 18y ago
  Exceptions are not meant to be handled where they occur, that's why they unroll the stack. For the most part, you can't recover from an exception -- you just abort whatever you're doing, print an error message, and let the user try something else. Checked exceptions cause developers to re-interpret the exceptions or just swallow them -- neither is a benefit.
  - jrockway 18y ago
    Exactly. If the database server blew up, there's nothing my program can do. I could try reconnecting, and some libraries do, but that doesn't usually help anything. Once the server is back up, the Fibonacci (or exponential) back-off is so high that's it's faster to just restart the program manually. So usually, dying is easier for everyone.
- wallflower 18y ago
  On a large CRM-type application I worked on in the past, database constraints were used to enforce stuff like unique login IDs. Yes, some validation could be done in the UI but that was the way it was done. When a user tries to create a user with a login ID that already existed, the database constraint is encountered and an Oracle exception is thrown. It is caught and and packaged up through the application stack until it becomes an application-level exception. The end user sees a localized, friendly message instead of seeing a raw, nasty ORA error message. I'm not sure how this could be done without checked exceptions.
  - arockwell 18y ago
    You can use unchecked exceptions exactly the same way with as checked exceptions. The difference is that you can ignore them and let them propagate up when it makes sense. A real-world example of your use case: The Spring framework repackages all SQLExceptions into a custom data access exception hierarchy. So, if you choose, you could catch a DatabaseConstraintException (or whatever the appropriate exception is, I'm not sure off the top of my head), and throw an application specific exception like InvalidLoginId.
    - wallflower 18y ago
      Thanks. That's cheating, you can't use magic :) We use Spring in our current app and I don't know how it does the cross-cutting it does; it just does.
arockwell 18y ago
That's pretty ugly, although I've seen a lot of that style of coding at my workplace as well. The problem is that there generally isn't anything useful to do once you catch the exception besides throw up an error page. You're probably bother off either throwing RuntimeExceptions or wrapping exceptions as RuntimeExceptions.

ricky_clarkson 18y ago

There are other return codes besides ints. E.g., replace a function that returns an int or throws an IOException with one that returns an Either<int, IOException>.