Showing messages 1 through 25 of 25.

• Tiffany jewellery
  2009-07-02 02:32:00 luckey_001 [Reply | View]
  
  Tiffany Sets. The trusted details. A permanent part of your everyday life. Tiffanys jewellery presents you with exclusive creations of Links of London that telegraph urban style, sophistication and a discerning eye.Tiffanys jewellery offer Links of London, hoop earrings, drop earrings , heart earrings and so on. Tiffanys jewellery is your best Links of London Silver jewelry online store.Tiffany jewelry based Links of london jewellery on sale, classic or modern stylish quality jewelry for both women and men.
  <hr>
  
  
  

• I chose no but...
  2007-06-28 06:20:05 hytparadisee [Reply | View]
  
  In my opinion, it is the RuntimeException that caused all the confusions. Exceptions should be either all checked, or all unchecked. I think the checked exceptions are powerful, but too powerful that it even overwhelmed the compiler. That's not always good though. In other words, the important thing is not whether to check or uncheck exceptions, but how the compiler/runtime respond to them. Why not just throw warnings instead of errors (just like those with generics) on checked exceptions, so that programmers, fortunately, would have a choice. (just talking rubbish here, because throwing warning instead of error will bring hell to the compiler designers lol)

• Not a problem
  2007-06-27 14:05:09 erickson [Reply | View]
  
  A method can throw a checked exception without declaring it. It's easy. It's just not something you should do very often, because it's a bit of a kludge, and (despite unsubstantiated hand-waving to the contrary) in most cases APIs correctly distinguish checked exceptions from runtime exceptions.

• Do they work?
  2007-06-26 05:32:20 valstadsve [Reply | View]
  
  An analogy: Premature optimization is considered bad, but some people argue that early (i.e. not TOO early) optimization isn't always bad. It can even be useful. I can agree on that. But, I think most people would agree that ALWAYS doing optimization from the very start would be not be a good practice. Now, imagine that the compiler somehow forced you to do just that.
  
  For me, it's the same with failure handling. Thinking about failure handling prematurely (i.e. too early) is not constructive, but thinking about failure handling early (i.e. not TOO early) can be good. However, ALWAYS thinking about failure handling from the very start is, like optimization, probably not a good practice. But the compiler does force us to do just that - which explains a LOT of the bad code I see in Java.

• RTFM
  2007-06-26 01:57:37 stridecolossus [Reply | View]
  
  I get rather worried when I see supposedly experienced developers so blantantly missing the point.
  
  There might just be a case for removing checked exceptions because they are so often misused. But to describe checked exceptions as broken for that reason is just plain wrong, and it's practically criminal to suggest they should be removed to accomodate the (rather ropey) implementation of closures!
  
  Instead, experienced developers should be attempting to educate the masses as to how to correctly use checked exceptions (and exceptions in general), and perhaps they also themselves need a quick refresher of Effective Java (assuming they have a copy).
• RTFM
  2007-06-26 08:16:01 jhannes [Reply | View]
  
  

  I am so tired of all the comments singing the praise of checked exceptions on a theoretical basis. I don’t care about what’s good in theory!

  Look over your code, look over the code of your peers. Look at the catch blocks. How many of them are just extra noise? How many of them ignore a potentially dangerous situation? How many of the simply wrap one exception in another exception? How many simply say “this can never happen”? How many contain bugs? How many are truly useful?

  Now, look at the code in the standard library, books and articles. How many of these do you think actually improve the reliability and maintainability of the code? Look at the exceptions Sun decided to make checked. Look at CloneNotSupportedException, look at MalformedURLException, look at ParseException or UnsupportedEncodingException. Look at your code that deals with these exceptions. Are you happy that they were made checked exceptions?

  Finally, take a look at the code base of the Spring framework. Is this unreliable code? This is the kind of code we will see if we get rid of checked exceptions. It’s the cleanest, most reliable code in the Java Open Source ecosystem.

  (from my blog)

  In theory, checked exceptions is a good idea. In practices, it makes code less reliable. That is what experience will teach you.

• RTFM
  2007-06-27 00:42:39 jwenting [Reply | View]
  
  So instead of checking for failure we should just let everything bubble up and bite the user in the face? Great, everything that can go wrong and could be handled now causes "abnormal program termination".

  Maybe some things that are checked exceptions shouldn't be, just as some things that aren't should be. A CloneNotSupportedException might be better off as an unchecked exception, but that would depend on the scenario where it's used (in most cases it would indeed indicate a program error and thus should come to bite you, but not always, maybe you want to handle it gently by logging it and providing a nice error message before moving on without the clone in say a plugin system). But a MalformedURLException should be checked. It's almost exclusively due to faulty user input, and should be handled through notifying the user which will often mean he can correct it without having the application crash.

  Seems you are one of those people who need to be educated on the correct use of different exception classes...

  Spring seems nice only because it deals with exceptions the only way it can, by throwing them up to the user (which will be another application) to deal with, often wrapping them in unchecked exceptions for good measure. Makes handling and dealing with problems in code that uses Spring a lot harder than it could be, as there's often no indication that something's going wrong and where except by digging through multipage stacktraces after your application crashes again because something somewhere went wrong. Spring itself may be reliable when it comes to exception handling because it does nothing but pass on the responsibility to someone else, but that's its job and no proof that doing away with exception handling altogether is a good idea.

  Experience has taught me that not handling exceptions (which using unchecked exceptions exclusively implies) makes code less reliable, harder to write and maintain (you'll never know an exception can happen somewhere because there's no indication of it...), and often less readable and even more error prone if you do try to handle them (just catch Throwable, log it maybe, and move on as if nothing happened...).

• RTFM
  2007-06-27 21:26:03 tompalmer [Reply | View]
  
  Java never provides any guarantees about exceptions anyway. Always assume any throwable can happen at any time. So be safe with finally (also too hard in Java), and by default stop exceptions only in the main loop (i.e., at the servlet container or gui framework). Work to map well known errors to useful error messages. Log everything only at this layer. That covers about 90% of use cases. Checked exceptions don't help any of this.
• RTFM
  2007-06-28 00:49:20 jwenting [Reply | View]
  
  You're so wrong... You should catch and handle exceptions where they can be, where it makes sense to do so, not at some random place you define as being the "divine power of exception handling", like a method in your main class that just logs everything and presents the user with an error message.

  Many checked exceptions (and that's what they were originally intended for) reflect conditions that aren't necessarilly fatal, could possibly be corrected or worked around, probably without the user ever being aware of them. Think of an error being caused by a temporary network glitch, often simply retrying the operation will give the desired result. Or there's an alternate path you can choose. Or a situation where you're processing a batch of data, some of the records in it may fail without crashing the entire run. Cause a checked exception to be thrown at failure and use those to log the failing records which can then be returned to the user. He no longer has to try and potentially fail for each record.

  Checked exceptions aren't perfect, that's why there are other mechanisms as well. People who think checked exceptions should be abandoned because they're not perfect are essentially just religious fundamentalists, rooting for something to the exclusion of all else, rather than choosing the best suitable tool for each job at hand.

  Sadly that attitude of looking for a Holy Grail, a tool that fits every job perfectly, seems to be rather prevalent among the otherwise usually well educated and intelligent people in this industry.

• RTFM
  2007-06-28 20:24:32 tompalmer [Reply | View]
  
  Except that people don't think through the careful way to handle things. They just silently leave the data in inconsistent state until everything's broken everywhere. Better is to crash (to the main loop) by default. Then handle the specific cases where needed. I said 90%, not 100%.
• RTFM
  2007-06-29 01:00:13 jwenting [Reply | View]
  
  I don't agree. So just because people may write buggy code you should make it harder to write code that's not buggy? At least by forcing them to handle certain exceptions you can give them a helping hand by indicating what conditions are likely to be non-fatal if properly handled.
• RTFM
  2007-06-27 07:34:36 valstadsve [Reply | View]
  
  Did it teach you that unchecked exceptions are catchable as well?
• RTFM
  2007-06-27 22:58:05 jwenting [Reply | View]
  
  Of course they can be, but you're not forced to handle them nor to make a deliberate choice to not handle them.

  As a result your code becomes more prone to not handling exceptions it can (and should handle) leading to a massive increase in errors causing abnormal program termination (or crashes, as they're also called).

• RTFM
  2007-06-26 21:57:06 tompalmer [Reply | View]
  
  Right on.

• Keep them
  2007-06-25 00:24:54 larswestergren [Reply | View]
  
  Checked exceptions have been helpful for me at least. It is enforcing good documentation standards so it helps understanding libs I use. When I have written slightly bigger apps myself, whenever I find that exception handling becomes unwieldy and starts to pollute method signatures, it has been a sign that I have structured my code incorrectly, increasing modularity has made the exception problems go away.
  
  I understand that in some problem areas and for some people it would be better without, but I think it is too late to make such a radical change in the way the language works now. Keep them please.

• Checked Exceptions
  2007-06-24 22:31:53 rickcarson [Reply | View]
  
  Not broken. Don't fix.

• In my experience...
  2007-06-24 00:43:47 stuartcw [Reply | View]
  
  In my experience, Checked Exceptions were helpful when used intelligently. Some thought has to be put in to the design of the Exception classes to prevent a proliferation of Exception types that need to handled individually. Grouping them into families that could be broadly handled reduced the exception handling code greatly.
  
  Code review greatly helped the situation. Just squashing an exception and not handling it all was considered an unusual case which warranted special documentation in the "do nothing" catch block to explain why this was a bug. Printing the stack trace was never acceptable.
  
  Almost all of the hard to find bugs were due to a squashed exception that had slipped through the net.
  
  Also, don't forget to exercise the Exception Handling code in your automated test cases.

• Checked Exceptions are very good
  2007-06-23 06:47:07 aehrenr [Reply | View]
  
  Checked Exceptions are a very good idea because you always know what error conditions you have to take into account. Therefore they increase the reliability of a program, especially one you have not written by yourself but you have to maintain. They are also very important when using libraries. Java is no language for the quick and dirty programming style or the quick hack to describe it more politely. There are many scripting languages for that purpose, one for every taste. Use Groovy or JRuby for the quickie but don't try to convert Java to yet another scripting language. I wouldn't become a good one anyway

• Checked Exceptions are ar
  2007-06-23 06:43:13 aehrenr [Reply | View]
  
  

• Visual Basic Clone
  2007-06-23 05:59:26 datavirtue [Reply | View]
  
  Java apps are very reliable. I remember creating VB apps years ago that would crash; had no idea why. Or they would run fine on MOST versions of Windows and then severly defect on others.
  
  Eliminating checked exceptions is unwise. It will go towards making Java apps less reliable, guaranteed. .net should be ignored, as though it doesn't exist. It hasn't a leg to stand on unless there is a Virtual Machine for every platform and then why not make it interoperable with Java? This is not possible therfore the doom to failure (if you want to call it that).
  
  It used to be I wondered about all these "new features" and APIs in Java and wondered, why? Now I just research .net (blissfully ignorant of .net) to find out why Sun has added this bloat to Java, its really sad. Sad that Sun would give .not the time of day.
  
  I'll shut up now.
• Visual Basic Clone
  2007-06-24 20:53:27 prunge [Reply | View]
  
  I also remember my VB days, how not writing error handling code would result in the entire app showing a runtime error dialog and then terminating. It was easy to fall into this trap too when writing code. Lots of VB apps I used worked fine in normal circumstances but failed miserable when, for example, a file could not be read from disk.
  
  In Java you will always be told by the compiler when you don't handle errors when dealing with files thanks to checked exceptions. Yes, it is more work on the developer's part, but that bit of extra work is worth it since apps will be more reliable.

• Never ever
  2007-06-23 00:06:09 bharathch [Reply | View]
  
  No f'ing way. And for those who don't understand why checked exceptions are needed, may I recommend reading the relevant chapters from effective Java?

• Java checked exceptions improve the contract.
  2007-06-22 17:54:45 kriggio [Reply | View]
  
  Java checked exceptions are an excellent part of the java language. They are a great aid in improving the ability to establish contracts within the code. They tell implentors that the method they are about to call depends on something that may not always be available and is outside of the control of this system. It also greatly contributes to the concept of the code being the documentation.

• Failed experiment
  2007-06-22 11:10:18 jhannes [Reply | View]
  
  Checked exceptions was a brave experiment, but it failed. My experience, and the evidence from code I've read is that checked exceptions have [em]reduced[/em] the reliability of code, not improved it.
  
  The fact that no other language author (that I know of, anyway) has lifted this feature from Java should tell you something.
• Failed experiment
  2007-06-25 08:10:46 mthornton [Reply | View]
  
  I don't consider checked exceptions to be a failure, but neither are they a complete success. Rather more work is required.