6 ms·

Checked exceptions are great, but unchecked exceptions are a huge disaster only mitigated by failsafe features such as RAII or garbage collection with finalizer

Checked exceptions are great, but unchecked exceptions are a huge disaster only mitigated by failsafe features such as RAII or garbage collection with finalizers. Sometimes like in highly dynamic languages the failsafes are enough that it's ok to just use unchecked exceptions, but in a language like C++ you really can't afford to make mistakes in the first place. The process of adding an exception in Java: 1. throw TheException 2. compile 3. add "catch(TheException e)" to fix errors or "throws TheException" to signature 4. repeat 2 until no more errors Compare to C++: 1. throw TheException 2. examine all functions to determine if they might need to handle TheException or consult intuition about program structure 3. repeat 2 until 'done' So the real problem with exceptions in C++ is the compiler can't tell you where to look next and what you forgot about. Step 2, magically find all the places that should catch the exception, is both time consuming and error prone. I find it strange that C++ has all kinds of strictness with types (have to cast void*, const virus, etc) but with exceptions they just throw caution to the wind.

MatthewPhillips 14y ago
Java is the only language that I can think of that gets exceptions right, in that it forces you to acknowledge them every step in the chain and choose whether you're going to catch them or throw them upwards.
- evincarofautumn 14y ago
  Haskell does this also, and its type system is much more expressive than Java’s, enough so that exceptions are not (exclusively) a built-in language feature.
- SeanLuke 14y ago
  Strange. It seems to me that the consensus in the Java community is that checked examples were among the worst misfeatures of the language. Googling for ---java checked exceptions--- is illuminating.
  - MatthewPhillips 14y ago
    That's interesting. I'm not a day to day Java programmer so my perspective is different from the Java community's. I have ran into problems numerous times in other languages where an exception isn't discovered until runtime in production because there's simply no way of knowing whether a library's function might throw an exception or not. The workaround is to be overprotective. I've always envied that Java devs know what to expect from every function they call
    - Anderkent 14y ago
      Your java library might still throw unchecked exceptions, so you have to be as careful as if all exceptions were unchecked.
  - JamisonM 14y ago
    It is strange that the consensus in the Java community sort of ended up being against checked exceptions. I for one think that this consensus is completely wrong and I suspect that what looks like a consensus is just a bunch of very loud people shouting down everyone else (and to me not making very compelling arguments). Elliotte Rusty Harold's brief post on this pretty much nails it for me: http://cafe.elharo.com/blogroll/voting-for-checked-exceptions/ http://cafe.elharo.com/blogroll/voting-for-checked-exception...
    - deleted 14y ago
      [deleted]
    - nostrademons 14y ago
      The problem is that it's a trade-off - it's not a case of one side being right or wrong. Checked exceptions introduce API fragility: when the implementation of a method changes in a seemingly inconsequential way (it may now throw an error), then all it's callers and all their callers, transitively need to have their signatures edited. What should be a simple matter between just the leaf method and the top-level now has to involve all the code between them, which may not even be in code you authored or controlled. Unchecked exceptions, however, mean that code that would previously always succeed may now never even be executed. Which makes it difficult to reason about the behavior of your function. It's the same trade-off that appears in several other areas of language design. Do you force developers to write down their assumptions in the source code, so that everyone reading it knows exactly what's going on? Or do you let them keep it in their heads, so that it can change easily when the system requirements change? Dynamic vs. static typing, global variables vs. parameters, polymorphism vs. conditionals, default arguments vs. explicitly specifying parameters - it's all the same fundamental argument applied to different language constructs. Which side your on usually ends up depending on whether you read more code or write more code. Maintenance devs always want things to be explicit, because it makes it easier for them to grok the whole codebase and make the change they need to do. Green-field innovators always want things to be implicit, because it means they have to specify less, and everything they specify tends to end up changing anyways. Sometimes the same person ends up cursing both ends of the divide depending on what they happen to be doing at the time. I do a bunch of speculative prototyping for Search Features at Google; in this role, 90% of my code never sees the light of day, and so I write it with tools like Python or JQuery that let me easily change things around and not specify too many of the details. I also do a fair bit of infrastructure work on the search stack; in this role, I write barely any code and spend the bulk of my time tracking down where an obscure piece of data is coming from and how it needs to be modified to add a new feature.
aidenn0 14y ago
Read up on exception specifiers in C++ and reconsider this comment.
- davedx 14y ago
  I just did; what I couldn't figure out, was is there a way to specify multiple different exception types in your C++ throw()? In Java, you can do: public int myfunc(int a, int b) throws IOException, InvalidGoatException {} How would you do this in C++?
  - cbsmith 14y ago
    You can do much the same thing, only the meaning is the reverse.
- signa11 14y ago
  > @davedx asks : is there a way to specify multiple different exception types in your C++ throw()? yeah throw() can contain multiple types that can possibly be emitted e.g. int foo() throw(a,b,c,d) implies that foo can only throw either a/b/c/d types.
  - Peaker 14y ago
    Except that is only enforced at runtime, and converts the exception type to unexpected_exception, which is even worse!
- pubby 14y ago
  Exception specifiers are deprecated and for good reason.

MatthewPhillips 14y ago

Java is the only language that I can think of that gets exceptions right, in that it forces you to acknowledge them every step in the chain and choose whether you're going to catch them or throw them upwards.

evincarofautumn 14y ago
Haskell does this also, and its type system is much more expressive than Java’s, enough so that exceptions are not (exclusively) a built-in language feature.
SeanLuke 14y ago
Strange. It seems to me that the consensus in the Java community is that checked examples were among the worst misfeatures of the language. Googling for ---java checked exceptions--- is illuminating.
- MatthewPhillips 14y ago
  That's interesting. I'm not a day to day Java programmer so my perspective is different from the Java community's. I have ran into problems numerous times in other languages where an exception isn't discovered until runtime in production because there's simply no way of knowing whether a library's function might throw an exception or not. The workaround is to be overprotective. I've always envied that Java devs know what to expect from every function they call
  - Anderkent 14y ago
    Your java library might still throw unchecked exceptions, so you have to be as careful as if all exceptions were unchecked.
- JamisonM 14y ago
  It is strange that the consensus in the Java community sort of ended up being against checked exceptions. I for one think that this consensus is completely wrong and I suspect that what looks like a consensus is just a bunch of very loud people shouting down everyone else (and to me not making very compelling arguments). Elliotte Rusty Harold's brief post on this pretty much nails it for me: http://cafe.elharo.com/blogroll/voting-for-checked-exceptions/ http://cafe.elharo.com/blogroll/voting-for-checked-exception...
  - deleted 14y ago
    [deleted]
  - nostrademons 14y ago
    The problem is that it's a trade-off - it's not a case of one side being right or wrong. Checked exceptions introduce API fragility: when the implementation of a method changes in a seemingly inconsequential way (it may now throw an error), then all it's callers and all their callers, transitively need to have their signatures edited. What should be a simple matter between just the leaf method and the top-level now has to involve all the code between them, which may not even be in code you authored or controlled. Unchecked exceptions, however, mean that code that would previously always succeed may now never even be executed. Which makes it difficult to reason about the behavior of your function. It's the same trade-off that appears in several other areas of language design. Do you force developers to write down their assumptions in the source code, so that everyone reading it knows exactly what's going on? Or do you let them keep it in their heads, so that it can change easily when the system requirements change? Dynamic vs. static typing, global variables vs. parameters, polymorphism vs. conditionals, default arguments vs. explicitly specifying parameters - it's all the same fundamental argument applied to different language constructs. Which side your on usually ends up depending on whether you read more code or write more code. Maintenance devs always want things to be explicit, because it makes it easier for them to grok the whole codebase and make the change they need to do. Green-field innovators always want things to be implicit, because it means they have to specify less, and everything they specify tends to end up changing anyways. Sometimes the same person ends up cursing both ends of the divide depending on what they happen to be doing at the time. I do a bunch of speculative prototyping for Search Features at Google; in this role, 90% of my code never sees the light of day, and so I write it with tools like Python or JQuery that let me easily change things around and not specify too many of the details. I also do a fair bit of infrastructure work on the search stack; in this role, I write barely any code and spend the bulk of my time tracking down where an obscure piece of data is coming from and how it needs to be modified to add a new feature.

aidenn0 14y ago

Read up on exception specifiers in C++ and reconsider this comment.

davedx 14y ago
I just did; what I couldn't figure out, was is there a way to specify multiple different exception types in your C++ throw()? In Java, you can do: public int myfunc(int a, int b) throws IOException, InvalidGoatException {} How would you do this in C++?
- cbsmith 14y ago
  You can do much the same thing, only the meaning is the reverse.
signa11 14y ago
> @davedx asks : is there a way to specify multiple different exception types in your C++ throw()? yeah throw() can contain multiple types that can possibly be emitted e.g. int foo() throw(a,b,c,d) implies that foo can only throw either a/b/c/d types.
- Peaker 14y ago
  Except that is only enforced at runtime, and converts the exception type to unexpected_exception, which is even worse!
pubby 14y ago
Exception specifiers are deprecated and for good reason.