Timeline for Overused or abused programming techniques
Current License: CC BY-SA 2.5
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 31, 2011 at 21:40 | comment | added | Dunk | This is why I despise API's that throw exceptions to return errors, like much of Microsoft's file operations. If I can't open a file or delete a file or whatnot, I don't need an exception thrown that forces me to clutter otherwise clean code with exception handlers. I simply report an error and continue on my merry way. A simple return result is far better and cleaner. Thus, the reason for the global catch. I could see your gripe as legitimate if the only time exceptions were thrown was because something truly exceptional happened, but that isn't generally true. | |
| Jan 20, 2011 at 16:04 | comment | added | Tom Hawtin - tackline | @zvrba Well one way you don't even need to run the program to see it is utterly broken. The other you have to get lucky and see the exceptional circumstance on your development machine. One of these wins for me. (I'm perhaps a little on the extreme end of the spectrum - my job has involved pressing Page Down an awful lot.) | |
| Jan 20, 2011 at 8:19 | comment | added | zvrba | @Tom: but at least the program would visibly crash. This way it will silently deliver nonsense results. Now, which is easier to debug? | |
| Jan 20, 2011 at 0:42 | comment | added | Tom Hawtin - tackline | @zvrba If the exception was unchecked, the source wouldn't make it glaringly obvious that the programmer didn't know what they were doing. | |
| Jan 19, 2011 at 17:19 | comment | added | yfeldblum | Ruby code uses this technique to try and load a better implementation of X and, if the better implementation is unavailable, later code will simply use the fallback implementation. | |
| Jan 19, 2011 at 8:21 | comment | added | zvrba | I think this is just a symptom showing that checked exceptions aren't a good idea :) | |
| Jan 16, 2011 at 19:16 | comment | added | user8709 | @jk01 - an exception isn't (necessarily) an error. Whether any condition is an error or not depends on context. For example, "file not found" isn't an error if you don't need the file. Perhaps it's just an optional settings file that may or may not be present, and you can just leave your defaults in place if the file isn't there (so no corrective action is needed after the catch). | |
| Jan 16, 2011 at 18:11 | history | edited | mu is too short | CC BY-SA 2.5 | Spelling fix: "shutter" != "shudder" |
| Jan 16, 2011 at 12:17 | comment | added | Frank Shearar | There is a huge difference between a catch that catches ALL exceptions, and a catch that catches A SPECIFIC exception. The poster is suggesting that catching ALL exceptions is probably not a good idea. | |
| Jan 16, 2011 at 8:41 | history | made wiki | Post Made Community Wiki | ||
| Jan 13, 2011 at 19:31 | comment | added | David Thornley | I wound up once having an empty exception block for what at least looked like a good reason at the time. I commented it to explain what was going on. Anytime I do something that's usually done for dumb reasons, I feel compelled to comment it. | |
| Jan 13, 2011 at 17:07 | comment | added | l0b0 | That's where things like Python's assertThrows or some such is great. | |
| Jan 13, 2011 at 5:44 | comment | added | Nickz | I agree if logging errors code throws an except what can you do but silently handle it. | |
| Jan 12, 2011 at 13:26 | comment | added | jk. | on error resume next | |
| Jan 12, 2011 at 11:51 | comment | added | user8709 | @dbkk - agreed on the edge condition, and I'd add that when you genuinely need to catch an exception but don't need a corrective action, adding a comment in the catch block to explain that is essential if only to calm down the maintainers. It's not so rare in unit tests, so I'd drop the comment thing in that case. | |
| Jan 12, 2011 at 6:19 | comment | added | dbkk | @Steve the case you described is an rare edge condition. Another one I can think of is logging code -- if logging itself fails, there's no point trying to log the exception, or interrupting the app. | |
| Jan 12, 2011 at 3:34 | history | edited | Nickz | CC BY-SA 2.5 | edited body; added 55 characters in body |
| Jan 12, 2011 at 2:44 | comment | added | user8709 | Funny thing - I've just been editing a file that does that hundreds of times, and with good reason. It's a unit test file, testing that various methods throw an exception when expected. The try block contains a call and an "expected throw didn't happen" report. The exception is expected and correct, so there is no corrective action. Obviously unit tests are a special case, but I have had similar cases in real code. Red flag, yes, but not an absolute rule. | |
| Jan 11, 2011 at 22:57 | history | edited | ChrisF | CC BY-SA 2.5 | corrected spelling |
| Jan 11, 2011 at 22:51 | history | answered | Nickz | CC BY-SA 2.5 |