Opinion: Exception Handling Debate is Back

Discussions

News: Opinion: Exception Handling Debate is Back

  1. Opinion: Exception Handling Debate is Back (65 messages)

    Exception handling is one of the topics that is always in debate. Fuel was added to the fire this week via a rant from Carlos Perez, which claims that both James Gosling and Anders Hejlsberg have missed the boat on exceptions. Carlos seems to think that OO is confining our thinking, and even links to Ron Bodkin, the AOP guru.

    AOP allows you to abstract your exception handling in many ways. You can create a policy for handling exceptions in separate aspects, and the code is forced to play by the rules. You can easily wrap checked exceptions as RuntimeExceptions (declare soft), and lots of neat things that can really help.

    Read The Exception Debate: Why Gosling and Hejlsberg are Both In Error

    Gunjan Doshi's Best Practices

    Best Practices for Designing your API

    1. When deciding on checked exceptions vs. unchecked exceptions, ask yourself, "What action can the client code take when the exception occurs?"
    2. Preserve encapsulation.
    3. Try not to create new custom exceptions if they do not have useful information for client code.
    4. Document exceptions.

    Best Practices for Using Exceptions

    1. Always clean up after yourself
    2. Never use exceptions for flow control
    3. Do not suppress or ignore exceptions
    4. Do not catch top-level exceptions
    5. Log exceptions just once

    Read the full article: Best Practices for Exception Handling

    Threaded Messages (65)

  2. In J2EE i.e EJB environment RuntimeExceptions are impractical for application logic. So if you're using J2EE save yourself sometime by not using RuntimeExceptions and staying out of this debate.

    'Nuff said.
  3. In J2EE i.e EJB environment RuntimeExceptions are impractical for application logic. So if you're using J2EE save yourself sometime by not using RuntimeExceptions and staying out of this debate.

    >
    > 'Nuff said.

    Do you mean that in J2EE environment RuntimeExceptions should not be used AT ALL? I think there is usually two top level Exceptions: ApplicationException and SystemException. I read that SystemException should extend RuntimeException. Do you think this is wrong?

    Another question of me is: Do you agree with the statement that Exceptions should never be used to control work flow?
  4. In J2EE i.e EJB environment RuntimeExceptions are impractical for application logic. So if you're using J2EE save yourself sometime by not using RuntimeExceptions and staying out of this debate.

    > >
    > > 'Nuff said.
    >
    > Do you mean that in J2EE environment RuntimeExceptions should not be used AT ALL? I think there is usually two top level Exceptions: ApplicationException and SystemException.

    To go one step further: in J2EE the use of unchecked exceptions probably makes more sense than in any other environment. The EJB spec requires a container to log any uncaught unchecked exception, rolls back the bean instance's transaction and discards the bean. Which happens to be just the thing to do when encountering an error and as suchm using unchecked exceptions has saved me a lot of time.

    \Ron
  5. Opinion: Exception Handling Debate is Back[ Go to top ]

    <snip>
    To go one step further: in J2EE the use of unchecked exceptions probably makes more sense than in any other environment
    </snip>
    Please avoid misleading the readers if you're not sure.
    The EJBException (SystemException in J2EE) gets thrown as a RemoteException in J2EE. The J2EE spec mandates that all SystemExceptions (aka RuntimeException) should inherit from EJBException. So you lose all the typing benefit of your exception hierarchy.
    By definition, SystemException means some infrastructure error. It should not be used for your business logic.
    Also, throwing SystemException (aka RuntimeException) results in instance destroyed and transaction rolled back. There are lot of side effects. It may not be necessary to do all these for Application logic scenarios.
    You want to control what you want to do when you throw a exception. You should cleanup anyway before you throw an exception. So using SystemException can cause unwanted cleanup.
    Another situation, that makes it undesirable using SystemException in J2EE environments is if you use StatefulSession beans. You lose your session if you throw a runtime exception from a StatefulSession bean because the container removes the instance.
    So the J2EE philosophy strongly discourages you from using RuntimeException.
    It makes this explicitly clear by denoting exceptions into two categories of exception i.e ApplicationException (aka checked exception) and SystemException (runtime exception).
  6. I would have liked to have seen more substance regarding HOW AOP is the answer to the exception "problem". He basically says it's the solution and just points to some AOP presentations, none of which seemed entirely relevant. Uh, ok...

    Another topic: NumberFormatException == RuntimeException, good or bad?
  7. Just borrowing from a technique introduced by Fermat. ;-)

    Carlos
  8. Just borrowing from a technique introduced by Fermat. ;-)


    So what then is the answer to Carlos' (hopefully not last) theorem? :)
  9. You might want to take the time to look at the slides to get some more details.

    But in general, remember the problems the C++ folks had with garbage collection and how Java (actually earlier OO languages) solved the problem. The problem is that garbage collection is a global and it's solution needs a global perspective. Same thing with exceptions, however its a little bit trickier since handling needs to be handle also at the local level. The other difficulty is that error handling seems to obfuscate the main line. Anyway the gist of it is that exception handling is a cross cutting concern that's best handled using AOP techniques.
  10. Well, to play devil's advocate here...

    Yes, garbage collection is a global concern... but it *wasn't solved* with AOP techniques. So even if we concede the point that error handling requires a global perspective, how do you make the leap that AOP is the answer?

    -Tim.
  11. I didn't say that Garbage Collection was solved by AOP techniques. What I was implying was that Garbage Collection couldn't be solved within the confines of the C or C++ language. In the same spirit, exception handling isn't going to be solved by OO techniques.

    The leap is pretty simple, how you handle garbage collection cannot be discerned at the local level, that is at the point you deallocate memory. Exception handling also cannot be discerned at the local level, at the point where you call a method. The difference between garbage collection and exception handling is that with the former you can develop a generic algorithm, with the later it is customized to its context.

    In other words, you need a mechanism to modularize a concern that crosscuts throught the sytem. So, can you thing of any technologies out there that does such a thing?

    Hmmm... this is getting a bit long... maybe I'll make thie a blog entry.
  12. I didn't say that Garbage Collection was solved by AOP techniques.


    Nor did I think you did. Sorry if my comment read otherwise.


    > What I was implying was that Garbage Collection couldn't be solved within
    > the confines of the C or C++ language. In the same spirit, exception
    > handling isn't going to be solved by OO techniques.

    I'm not sure I see the connection to the OO paradigm. Surely you can have garbage collection in functional programming. Why should we conclude that exception handling "isn't going to be solved by OO techniques"?


    > The leap is pretty simple, how you handle garbage collection cannot be
    > discerned at the local level, that is at the point you deallocate memory.
    > Exception handling also cannot be discerned at the local level, at the point
    > where you call a method. The difference between garbage collection and
    > exception handling is that with the former you can develop a generic
    > algorithm, with the later it is customized to its context.

    Well, memory management *can* be handled at the local level... as you point out, that is how C/C++ work. And exception handling can certainly be handled at the local level, which is how Java currently works.

    In the case of garbage collection, Java code is freed from this responsibility at the local level... and instead it is centralized to the garbage collector. So I can see the value in shifting that to a global responsibility.

    However, as you point out, it's not so simple with error handling... since you cannot centralize to a "generic algorithm". Error handling *is* contextual. So it may seem non-obvious why error handling should be handheld globally.

    You're arguments against Gosling and Hejlsberg (as I understand them) seem to relate to one requires too many throws declaration, and the other not enough... does making error handling a global responsibility solve this?


    > In other words, you need a mechanism to modularize a concern that crosscuts
    > throught the sytem. So, can you thing of any technologies out there that
    > does such a thing?

    Those are other words... in fact, very different words. If we put the AOP hammer away, does it still look like a nail?


    Perhaps if I understood better what we were trying to acheive, I could better evaluate whether AOP is an appropriate fit...

    -Tim


    BTW, let me say that whenever checked exception vs. unchecked exception debates come up... the religions come out of the woodwork. One side says "checked exceptions suck because..." and then the other side says "no, unchecked exception suck because..." To me, it seems unreasonable that one complete side is *wrong*. Instead, it suggests to me that there is a 3rd possibility that hasn't yet been considered.

    I welcome this opportunity to move beyond the same old exception debate and on to figuring out something that works better... regardless of whether or not Carlos holds the answer.
  13. I found it interesting that one of the first examples in the AOP slides was how to achieve servlet content caching using AOP. Servlet filters could do that too. AOP would be very useful when the api is fixed, but if you can change it, the point cuts can be achieved in code. So instead of thinking of AOP as some new paradigm, I consider it as a nifty way to fix broken or static api's and handle logging. Oh yeah, you can warn developers not to use "println()". Is that a revolutionary new paradigm in software development or just a nifty tool?

    Taylor
  14. Opinion: Exception Handling Debate is Back[ Go to top ]

    Carlos Perez doesn't know what he's talking about, and his article so much fluff, I can't believe it's reposted here (or can I?). It provides nothing of value, and just because he says those two guys are wrong, doesn't mean anything! He doesn't back up his claims AT ALL. The burden of proof is on him and as usual, he provides none of it. Please stop reposting his crappy blog here.
  15. Opinion: Exception Handling Debate is Back[ Go to top ]

    Dave,

    What's with the attitude? Are you some kind of Microsoft supporter?

    Seriously though, I did point out why Gosling was wrong about checked exception not scaling and I did point out why Hejlsberg was wrong about not having a throws clause. So what did I miss?

    So, if you don't agree with my conclusion that AOP is the right direction to fix exception handling, can you please provide some alternatives?

    Carlos
  16. My thoughts[ Go to top ]

    I don't pretend to know more than Gosling or Hejlsberg or even you Carlos, but I do know that when you say something like

    "That is the inventor [sic] of Java and C# have both [sic] a crummy understanding of the matter."

    you need more than a link to your own blog to back up your claims. It feels a bit too straw man.

    Your article is long on conclusions and short on details. For instance you say:

    "Both seem to be holding to the party line, ignoring the true arguments, the fact is plain and simple, both languages do not adequately address the problem. That's because it's outside the realm of Object Oriented Programming where both Java and C# derive their underpinnings."

    I will number my responses to this for clarity/brevity

    1) What is the party line that they are holding? Is it a stated philosophy or practice that they have a stake in AND that spills over into their treatment of exceptions?

    2) What are the true arguments they are ignoring. These are not explicitly spelled out anywhere in your article. What makeds them the "true" arguments?

    3) What problem are both languages not adequately addressing and how do they fail? You mention that checked exceptions don't scale (with a link to one of your own articles as evidence) and that C# makes it hard to discover what exceptions a method may throw, but you never discuss what the central issue is with error handling or even if it has to be covered with exceptions at all. From what you point out as flaws I can divine that compile time checking and scalability are two things you think should be componenents of a successful exception handling framework. Is that all there is? Why? You don't even point out how AOP provides for those two things. You simply assert that it does.

    4) What is fundamental about Object Oriented programming itself (not just Java and C#, you took on a significant burden there) that makes it unable to deal with your (unstated) central problem surrounding exceptions?

    You then go on to state that AOP is the answer without even a cursory demonstration of how that would happen.

    You seem like a nice guy, but if you want people to take you seriously then you will have to provide a better demonstration of WHAT you think the central problem is, HOW current solutions are inadequate, and WHY your conclusions are correct.

    Gosling and Hejslberg have a lot of credibility and when you challendge their statements in such a bold fashion you place a huge burden yourself. There is nothing wrong with that, but you need to meet that burden.
    I, it looks like others, feel that you have not.
  17. apologies[ Go to top ]

    Please excuse the random d's sprinkled in the above post. My d key has been sticking/mis-firing.
  18. My thoughts[ Go to top ]

    Okay so I'm slaughtered a couple of sacred cows in the process of making a point. That's life, I pinpointed which part of the interviews that I felt they were incorrect and I offered in general an alternative to the Exception debate.

    The exception debate is real as evidenced by the Bruce Eckel link, the C2 Wiki discussion and the fact that they were even brought up in both interviews. To believe that its no big deal is simiply naive.

    The party line I refer to is that Java's or C# design choice was correct. My take is that static checking has its flaws and the absense of a throws clause is also a flaw. I'm not the only one who has pointed this out.

    Now obviously just because these two folks are in error somewhere doesn't mean that they're in error everywhere. I simply pointed out where, nothing wrong with that, its not like these guys are perfect!

    Now regarding AOP, its got potential as I've pointed out in my earlier responses here.
  19. potential for what?[ Go to top ]

    Now regarding AOP, its got potential as I've pointed out in my earlier >responses here.


    Top 5

    5. A new element in the periodic table.
    4. A name for madonna's next child.
    ... got cross cutted
    2. A lyric in a rap song.
    1. A revolutionary new programming pair-of-dimes that nobody
    quite get across what it does?

    Details would be helpful for those of us who have
    not had the AOP kool-aid.
  20. potential for what?[ Go to top ]

    Hey it's not like I've got all the time in the world to give you an education.

    On the other hand, I know Ron Bodkin is on a talking circuit so you may just have the oportunity of paying him for some enlightenment. Here's his schedule:

    http://www.aspectmentor.com/
  21. potential for what?[ Go to top ]

    You have time to post multiple messages that don't
    give a single detail, so you have time to make one
    message that at least tries to provide some sort of vision.
  22. potential for what?[ Go to top ]

    Now, be nice, thoff... I assume Carlos didn't ask for all this attention, he just blogged his thoughts and they got picked up by TSS. If he doesn't have the time or energy to continue this discussion, we should respect that.

    But if I read Carlos correctly, he is saying that the "AOP solution" to error handling isn't really his per se... its Ron Bodkin's. So perhaps someone else who is familiar with Ron's position on the subject could provide some illuminating detail...

    -Tim.
  23. Friends or what[ Go to top ]

    Are u guys friends or what ?

    Seems like, any tpoic post from Mr Purdy or Carlos get posted by
    Dion - unmoderated.

    What is the truth ?
  24. Friends or what[ Go to top ]

    Yeah, I forgot all about that too, Cameron Purdy got top billing here for his equally provocative blog entry "Open Source Sucks".

    I don't know but is there are new rule here? "Thou shalt not quote blogs"

    But wait a second here, this is entry is posted as dion's blog entry, so should it now be "Dion's blog shalt not quote blogs"?.

    Anyway, I digress.

    Like another reader reemphasized, you want exception nirvana go ask Ron Bodkin.

    Ask for asking me, well if I put a $5.00 microcontent piece on it, I'm curious would there be any takers?
  25. potential for what?[ Go to top ]

    Carlos responded on this board. I have not been unkind.
    It is not mean to ask for a little backup for an assertion
    across several messages.
  26. Opinion: Exception Handling Debate is Back[ Go to top ]

    To quote:

    "I'm simply stunned, forms of static checking like checked exceptions tend to have problems scaling. To say that he hasn't seen it is more like trying to wish the problem away by refusing to see it."

    So, you are saying that you just don't believe him? Hardly a rigorous proof. Your only remote proof is the link to your idiotic article about static checking being evil.

    As for Hejlsberg, well, it isn't some revelation that you picked up on a subtle difference between what happens and what he was saying. He larger point is that for non-runtime exceptions you have to either handle them or declare that you throw them. You can argue about the utility of runtime exceptions, but most sane people use them for what they are intended, which is unexpected error conditions and programming errors.

    So, there is nothing wrong with exception handling, if you just sanely program your code and properly design your classes.

    So the alternative is to just design your classes ahead of time. Gosling is right when he says that having a throws clause with more than 1 exception is rare. It's usually an indicator of a design issue.
  27. It does not matter if you invent Java or C# or write a good article. What matters is What "The Carlos Perez" says. If you say anything against Him, it comes back as an attitude. However "The Carlos Perez" can go ahead and critic anyway without any sane thoughts and that is fine. Why? He is the boss!!!!


    Make way for Carloz. :) How about naming the next language after his initials "cp" :)
  28. Jimmy,

    Well thank you for your first and only post at theserverside.

    Also thank you for the ringing endorsement.

    Now I'm curious why do all my critics "Dave C", "thoff thoff", "Jimmy Carter" use "anonymous" pseudonyms?

    Word of advice, if you want to become any good as a critic, you better be prepared to put your name and reputation on the line. So how about it folks, prepared to unmask yourselves?

    Carlos
  29. We do not want to identify ourselves with your crappy posts. I do not want my friends to be making fun of me "Hey Jimmy, you replied to Carloz's post. hahaha".

    BTW. Do not get emotional. It happens to the best of us. :)
  30. Carlos, thoff is my first initial and last name.
    I am hardly anonymous. Now please, say something
    technically useful. I am actually very interested as
    i think this is an interesting problem, indicative
    of deeper issues between layers.
  31. I agree with Dave. I liked this snippet from the blog:

    "I have never experienced a problem with the scalability of throws clauses and my system grows. I have also never needed to write huge throws clauses in my method signatures.

    I am baffled. Why do people have this problem? Do they not apply the same care to the design of their exception class hierarchy as to their functional class hierarchy? Do they not refactor their exception classes as mercilessly as they refactor their functional classes?"
  32. "o they not apply the same care to the design of their exception class hierarchy as to their functional class hierarchy? Do they not refactor their exception classes as mercilessly as they refactor their functional classes?"


    Well like the response in the blog. You don't always have the luxury of refactoring mercilessly. Have you ever taken a look at the JMX api?
  33. Off topic (to Carlos Perez post).

    I mean I understand TSS needs clicks and traffic to stay in business... But I would appriciate if more technical screening would be done before posting something of that level. Going this way we may end up having adult ads on TSS just to keep the traffic up...

    Regards,
    Nikita.
  34. Why is this on TSS[ Go to top ]

    Hi -

    This post was about both the comments that Carlos has made, and the best practices article that was just released.

    Exception handling is an issue that has dogged developers for awhile, and both of these pieces said a little more on the issue.

    I also think that Ron Bodkin has some excellent points when it comes to handling exceptions as a cross cutting concern (and AOP).

    That is why the thread was posted.

    Cheers,

    Dion
  35. Why is this on TSS[ Go to top ]

    Hi Dion,
    I think you are spinning the issue here... If you would post Rod Bobkin's article I would have no problem. Posting something like original post is a different category of its own.

    Regards,
    Nikita.
  36. Why is this on TSS[ Go to top ]

    Nikita,

    I would submit that the onjava article on best practices is also equally useless.
    It's the same stuff regurgitated by the Eckel article. Matter of fact you could check any good static checker (i.e. PMD) and its got all the rules mentioned in the article. It's nothing new but it gets front page billing at onjava. Hey at least I wrote up something novel!

    Carlos
  37. Why is this on TSS[ Go to top ]

    I see where you are coming from Nikita.

    All I can say is that I saw a couple of pieces on the subject and thought some people would be interested in them.

    We are going to have a series of articles on TheServerSide coming up, and part of that series will touch on exception handling.

    Thanks,

    Dion
  38. Static vs. dynamic[ Go to top ]

    Checked vs non-Checked is like static vs. dynamic.
    It's kindof a religious war.

    For me it's simple: if the error is part of the interface of your method, then it should be checked (using an apropriate abstraction for the exception, and preferably only ONE exception per method).

    Maybe that is too simple..

    But the advantage of checked is analogous to static type checking. You are not allowed to misuse the method. Meaning, you are forced to handle what the designer intended you to handle.

    Non-checked for programming bugs (assertion failures)..

    I completely disagree with Eckel.. I think he's not "Thinking in Java". C++ doesn't have checked exceptions and figuring out what exactly you have to handle is a pain (and do you remember error checking in C???). Checked exceptions lets the compiler figure it out.

    On the other hand.. if you are on the dynamic side of this debate you may not see the benefits of the static side..
  39. Static vs. dynamic[ Go to top ]

    For me it's simple: if the error is part of the interface of your method, then it should be checked (using an apropriate abstraction for the exception, and preferably only ONE exception per method).

    >

    Quick question: if you make an exception part of the interface won’t it violate rule 2 of best practices “Never use exceptions for flow control” ?

    oleg
  40. Re: Static vs. dynamic[ Go to top ]

    No. Using exceptions for flow control is this:

    // Never do this...
    try {
      int i = 0;
      while(true) {
        System.out.println(array[i++]);
      }
    } catch (IndexOutOfBoundsException e) {
      // ignore
    }

    What I'm talking about is saying (contrived example):

    public void searchInFiles(File path) throws SearchFailureException ..

    Here I declare my exception because access to a network path may be forbidden (Maybe I could have used IOException just as well in this case).

    Whether you are using C++, C#, Smalltalk, or Java or even languages w/o Exceptions, error handling IS part of your interface already, so you might as well make it explicit and let the compiler find errors of misuse for you.
  41. Re: Static vs. dynamic[ Go to top ]

    not sure what is the exact definition of flow control is, what i saw is a management of data flow in communications, but it is probably smth. different, for me it sounds smth. like this "to process things in certain order", like in frameworks and checked exceptions behave exactly in such a way. maybe this rule should be modified to say don't use unchecked exceptions for flow control, that is what is your example demonstrates. or maybe checked exceptions is an oxymoron and not really exceptions anymore in a sense that smth. unexpected happens. in case of checked exceptions smth. happens that you actually expect and should be prepared to process. After all it is quite unlikely that stack trace will be used to recover from checked exceptions.

    i am not sure that error handling is part of the interface in all other languages, take for example errno in C.
  42. Re: Static vs. dynamic[ Go to top ]

    Basically do not use Exceptions as part of the normal flow. The example shows an Exception being used to end a loop. The Exception will always be thrown whenever the code is executed whereas Exceptions should be reserved for exceptional situations, i.e. for things that may happen, but should not happen as part of normal processing. For a contrived example assume that a file is expected to be present and you want to open it. In this case handling the FileNotFoundException is the correct thing to do as it is an exceptional situation. If the file may or may not be present then it's probably better to check with file.exists() before trying to open it. (of course you'll still have to deal with the exceptions but then they are not part of the normal flow)
  43. Re: Static vs. dynamic[ Go to top ]

    Question on example with FileNotFoundException: if you have alternative location to look for a file then is it the part of the normal processing, and if there is no alternative location and you have no way to recover just to inform the user then you might be better off with unchecked exception.

    oleg
  44. Re: Static vs. dynamic[ Go to top ]

    Question on example with FileNotFoundException: if you have alternative location to look for a file then is it the part of the normal processing, and if there is no alternative location and you have no way to recover just to inform the user then you might be better off with unchecked exception.


    I use unchecked exceptions to KILL the app! (ok, not always, in a Servlet it won't actually kill the app, just the transaction)
    If the app must die, I throw it.

    The FileNotFound example is a good one. Say I'm looking for a config file for an IDE. If i can't find it, I can:
    (1) inform the user, create a new one
    (2) just create a new one

    The value of letting the user know is that maybe the user moved the instalation or something and hasn't properly restored the config file. Or maybe it is shared and he hasn't hooked up the net right.

    The exception is checked because it isn't a programmer error (ok, not all authors agree on this), therefore my UI has to respond to it somehow. Since I don't want my app to die, I use checked exceptions to ensure that it is properly handled.

    Of course, a lot of people disagree w this. I think it makes sense. I want explicit interfaces.
  45. Is TSS becoming a joke?[ Go to top ]

    I can't believe this made it on TheServerSide. A guy makes a blog entry that attacks people like Gosling and gets press for it? He barely even attempts to back up his statements with proof. He says checked exceptions are expensive but doesn't provide proof other than to say that Gosling has his head in the clouds since Gosling doesn't believe it's a problem. Personally, I think they are expensive but I can't back that up with any metrics since I haven't done any measurements. Had Carlos backed up his statements with any science, it might have been worth it to bring it to TSS. He didn't, so it's worth nothing except to excite flames and formless arguing.

    Perhaps TSS should just start posting the blog ramblings of all java programmers. Who cares if they are worth anything?
  46. Is TSS becoming a joke?[ Go to top ]

    Marc,

    When I refer to checked exception not being "scalable" I don't imply it on the "performance" sense.

    If you bothered to study the referenced link then you would understand what I'm talking about.

    I'm increasingly getting tired of hearing wet-behind-the-ears developers whining about something they clearly don't understand. I mean, look at one of those responses on my blog, the guy claims to have written a 500K+ line system, and he reasons out that he declares a throws clause to improve performance. C'mon give me a freakin break! Where do these people come up with these ludicrous ideas?

    Carlos
  47. Is TSS becoming a joke?[ Go to top ]

    Alright, I take back my previous comment. Apparently, Carlos has time to respond to every comment *other than* those asking him to back up his wild assertions.

    "Gosling is wrong!
    Hejslberg is wrong!
    I have the answer!"

    "Wow, I'm intrigued... tell me more..."

    "I don't have time to explain it to you mere mortals."

    Hehe... ok... thank you for playing, Carlos... please pick up your parting gifts on the way out.
  48. Is TSS becoming a joke?[ Go to top ]

    Tim,

    I answered your queries above didn't I?

    Like I said, if you want the full essay then you'll have to wait till I have the time to conjure it up in my blog.

    As far of the rest, well they've been complaining about a lot of things that didn't make sense, so coming up with a response would require just a sentence or two.

    Carlos

    Next question!
  49. Is TSS becoming a joke?[ Go to top ]

    Tim, you had better watch your mouth. This Carlos guy is a freakin' genius!
  50. Is TSS becoming a joke?[ Go to top ]

    Wow! Did you realize that this thread has 48 "vacuous" comments already!

    If this keeps up, it'll displace Cameron Purdy's "Why does open source suck?" thread on the hot threads list!

    BTW, I would like to thank Dion and TSS for plugging my piece, it's been a healthy boost in traffic the past few days. Thanks guys! TSS rocks (obligatory plug )!
  51. Is TSS becoming a joke?[ Go to top ]

    Carloz:
    Some advice:
    Openly blogging against Gosling and Hejslberg without any metrics may increase traffic to your website for short time.
    Trust me, it is not going to last long. You are becoming a joke.
  52. Is TSS becoming a joke?[ Go to top ]

    Interesting, Erik Thauvin has also picked up my post and has published it in JDJ's weekly newsletter.

    http://www.thauvin.net/blog/stories.jsp?id=82

    Thanks Erik!
  53. Re: Is TSS becoming a joke?[ Go to top ]

    I have enjoyed many postings by Carlos, and I am sorry to say that, but here it goes. Your last statement.... How does it matter?

    It's just my personal feeling, yet I think it's been shared by many others.

    Carlos, if you want to make a clear point, please go with facts and careful observations, please care to back up you judgements. Names dropping (A is wrong, B is right) is fruitless; crying Wolf! is plain childish. Please make your message clear and to the point. Excuse me: I have failed to see the point so far.

    Also, please allows other people to publicly analyze your statements and to openly criticize them: ya know, some of us can have a point, too. Saying
    'Next!' is outright rude and demeaning to this community.

    Thank you.
  54. Re: Is TSS becoming a joke?[ Go to top ]

    Sergey,

    Last comment is in reference to the both the "traffic" remark and the remark that the post wasn't worth citing.

    Carlos
  55. Is TSS becoming a joke?[ Go to top ]

    Carlos, had you bothered to read my post more carefully you would understand that I don't really care about any of your particular arguments other than to say they weren't very specific, nor were your claims substantiated. It's a blog so that's perfectly fine. You're not obligated to do anything. My critique is against TSS for posting this as a headline item. No offense to you, but frankly it shouldn't have been.
  56. Is TSS becoming a joke?[ Go to top ]

    Marc,

    You're trying to re-spin your last statement, I think its clear that in addition to your critique of TSS you've attacked the merits of my post.

    Here's what you said:
    "He says checked exceptions are expensive but doesn't provide proof other than to say that Gosling has his head in the clouds since Gosling doesn't believe it's a problem. Personally, I think they are expensive but I can't back that up with any metrics since I haven't done any measurements."

    So how does someone who comes up with the above statement be allowed to judge what's technically appropriate in TSS or not?

    You're probably the fourth person who has posted that thinks that he was referring to "performance". What Gosling, Hejlsberg and Venners were referring to was "manageability". Curiously enought it is in the URL of my blog!

    Carlos
  57. Experience, and The Meaning of Words[ Go to top ]

    First, to your critique of the 500K+ lines poster:
    Could it be that the logic required to determine whether or not an exceptional condition were occuring was more expensive than simply throwing and handling the rarely occuring exception? I don't know. I, as you, have no knowledge of the system's internals.

    Second, to the meaning of "scalable":
    > When I refer to...not being "scalable" I don't imply it on the "performance" sense.

    I take it, then, that you are referring to the productivity of the development and maintenance efforts. That is, that maintaining a coherent exception hierarchy across a reasonably complex system is itself a complex task--or set of tasks; and that, as the system grows, these tasks become unmanageable.

    This "maintenance scalability" of exceptions is definitely an issue, for which I don't think anyone has proposed a reasonable solution. I know that you proposed (and perhaps still do propose) AOP as the answer. I need to look more into how AOP addresses the problem. It hasn't clicked yet how maintaining the handler logic for an exceptional condition separate from the logic that triggers the exceptional condition would be more easily maintained.

    In any case, although your definition of scalable is understandable, it is not the first definition in the book. When Gosling was asked about the scalability of exceptions, my impression was that both he and Bill Veneers were thinking of performance scalability. Of course, it's tough to know what any one person is thinking, let alone two.
  58. Experience, and The Meaning of Words[ Go to top ]

    Joe,

    As far as the 500K+ lines poster, I for the life of me don't have a clue as to how using a throws clause in method signatures affects performance.

    I think your spinning it here about the use of the word scalable in the interview. It's pretty unambiguous as to what Bill Venners was referring to, in fact he quotes the response of Hejlsberg who says that "It just balloons out of control".

    In other words scalability in the "manageability" sense and not the "performance" sense. That's clear as day.

    Bill Venners earns his keep by doing good interviews, I seriously doubt that these two folks didn't understand what they were talking about.

    Carlos
  59. Re: Static vs. dynamic[ Go to top ]

    i am not sure that error handling is part of the interface in all other languages, take for example errno in C.


    It isn't part of the "explicit" interface, but it sure is a part of its "implicit" interface. When I say interface I mean not only method signatures, I also include all the instructions that allow you to properly use the method.

    For example in C:

       sprintf(buff, "%s%d", a, b);

    This code should have checked for errors, because maybe a or b could not be converted for some reason. The C documentation tells you this, but how many programmers take head. errno is no different. If you don't check it, you are violating the contract w/ the api author.

    The wonderful thing about checked exceptions is that you are making these dependencies part of the explicit and statically checked interface. I'm sure some C programmers didn't like it when we started forcing them to only send the right argument types to their functions, but it reduces errors.

    Programmers often focus on initial dev costs, the real cost is not dev, but the test-debug and maintenance cycles... these will kill you. Checked exceptions slow you down initially but give you a standard error checking mecanism aided by the compiler. I have no idea why people don't like this.

    I don't agree w the author who says that we should ONLY use checked exceptions when we can recover. I'd say use them when you don't want to kill your app (GUI) or web transaction.
  60. Re: Static vs. dynamic[ Go to top ]

    Programmers often focus on initial dev costs, the real cost is not dev, but the test-debug and maintenance cycles... these will kill you. Checked exceptions slow you down initially but give you a standard error checking mecanism aided by the compiler. I have no idea why people don't like this.

    >

    i think Bruce Eckel answered this question at
    http://www.mindview.net/Etc/Discussions/CheckedExceptions
    http://mindview.net/WebLog/log-0025
  61. Re: Static vs. dynamic[ Go to top ]

    While I agree that there is merit in dynamic typing (I often prefer it.. in fact I dislike generics inmensely.. I think they are unnecessary). Static checking has its merits too.

    Bruce Eckel is not "thinking in Java". Maybe he's thinking in Python, or C++, or C#. His arguments may be convincing to many but aren't to others (I think Gosling disagrees, and so does Joshua Bloch in his book). The ignored exception problem he refers to is silly, because in Java if you ignore a checked exception you have to do it explicitly. That is a feature not a bug. Because in production coding you can check. I've used Checked Exceptions extensively since 1999 and haven't had all those nasty problems they are FUDing about. In fact I've only seen benefits. But you have to follow Bloch's guidelines at a minimum to avoid the problems that the C# proponents (I think it was Heisberg interviewed by Bill Veneers) alude to (having a zillion exceptions in your throw clause) because they don't understand exception encapsulation.

    Checked exceptions are part of the Java philosophy. If you don't like it use C# or Python or C++. I hate generics, but I won't dream of doing C++ w/o templates.
    Java is a bit of a purist language (I tend towards that) like Pascal (that is why many University profesors like it).
  62. Re: Static vs. dynamic[ Go to top ]

    Checked exceptions are part of the Java philosophy. If you don't like it use C# or Python or C++. I hate generics, but I won't dream of doing C++ w/o templates.

    > Java is a bit of a purist language (I tend towards that) like Pascal (that is >why many University profesors like it).
    >


    Probably there is no perfect language around. And the solution is - the folks who disagree with any single feature of the language should be forbidden from using the language. Don't get me wrong, I like java and at the same time think that still there’s room for improvement.
  63. I actually think that Carlos is right, with the AOP approach you could then create a generic Exception handler for a whole stack of exceptions.

    My only concern is how this would affect the recoverability of your program when an Exception is thrown, this is normally quite easy when your exceptions are handled locally. I must read more...
  64. Heinz Kabutz chimes in[ Go to top ]

    Heinz Kabutz of the Java Specialist's newletter and fellow blogger at artima has a piece on GUI exception handling.

    He writes at the end of his piece:

    "This solution is far from perfect. In my industrial-strength exception framework (not available for general use, don't ask), the uncaught exceptions go to a central place from where they are dispatched to the correct listeners. Those might be more fancy dialogs, or emails sent to the support team, or a stacktrace in a log file."

    Oh, this is just great, another guy with an exception framework that's not available for public viewing! Oh, btw, speaking about Ron Bodkin, yeah his stuff WAS available a java.net under the atrack project. Unfortunately for some strange reason it was also deleted. Hmmmm.... conspiracy here?
  65. Heinz Kabutz chimes in[ Go to top ]

    Um, ok... AND?!?!?!

    Heinz is blogging about using a centralized exception handler in a specific problem domain (GUI apps).

    1. He isn't claiming that it solves the proliferation of 'throws' clauses, which is your issue with Gosling

    2. He isn't claiming that it solves the ambiguous exception contract problem, which is your issue with Heljsberg

    3. He isn't using AOP... which is your 'answer'


    So how exactly does this contribute to the current discussion?

    -Tim.
  66. Heinz Kabutz chimes in[ Go to top ]

    It's an argument against the folks who think "exception handling" isn't a problem.