- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
frist
Admin
// try { puts("first!"); // } //catch (TooLateException e) { // puts("second!"); //}
Admin
Alex? WTF!
Admin
Wait, they care enough about code quality to develop tests for the plugin, but ban exception handling?!
Admin
So the "experienced" guy with 30 years was the one saying don't worry about exception handling? Now that's the WTF.
Admin
Actually having a lot of try catch blocks is an antipattern imho.
You should fix the code that is causing the exceptions. Not catch and handle them. In most cases there should be only one global exception handler that just logs the exception and then shut the application down. Fail fast policy basically. Most of the time when an exception got caught, the application will be in an corrupt state, so it's best to just shut it down & restart.
Exception to this: everything external (database calls, file IO, ...) should be guarded with exception handlers.
Admin
30 years experience, and accepts a job at a two-bit hacking shop. Yeah, he wouldn't worry about error handling.
Admin
TRWTF is that this story is repeated in the C# era, when the lessons should have been learned long before that.
Admin
C# doesn't allow a try without a catch or a finally. try{ } finally { }
is good.
try { } catch { }
is good.
try{ }
by itself is an error and the code won't compile.
Admin
Well, crap. The forum software ate the formatting. Oh , well. I'm not going to try to figure out yet another formatting dialect.
Admin
This is the kind of idea that forgets the second part of your post: All of the stuff that can throw exceptions without bugs in the code.
Admin
Why do people not realise that exceptions don't always mean bad code? A missing or corrupt file is an exception. You can write the best code in the world and still produce exceptions.
Admin
Indeed, you do not need exceptions if your functions return an indicator telling if (and why) they failed. Example: int DB->get(DB *db, DB_TXN *txnid, DBT *key, DBT *data, u_int32_t flags); What was good 30 years ago, cannot be wrong today.
Admin
macOS and iOS code using Objective-C doesn't handle exceptions. Exceptions are used to indicate programming errors. You set a breakpoint to catch all Objective-C exceptions when they are thrown, and if one is thrown, you have a bug and fix it. (Non-existing files etc. are not exceptions).
Admin
Wow. It's been a while since one of these made my jaw drop.
Admin
Let's say for sake of argument that you could write your code to handle anything that might ever happen to it. Problem is that your code is going to be so full of crap dealing with the exceptional cases that the actual logic of what it's trying to achieve will be completely hidden. Proper use of exceptions gives you cleaner, more maintainable code. Anyway, gotta rush, need to catch up with my gran for her egg sucking lesson
Admin
Nice sweet, so how often do you check to see if the file still exists? I need to read from a file. Does it exist? Yes, read from it. No, return a value saying it didn't exist.
What happens if it existed when you checked, but during read it vanished for some reason; it got deleted, moved, the server connection dropped, etc.? This is still an exception state due to a possible race condition, you CANNOT account for all of these without exception handling.
Admin
Wait, they didn't know they could use #if or #define to globally hide/show try/catch/finally? Sounds like they are REAL noobies.
Admin
I am forced to use this ERP software on a daily basis... It is called "Visual Enterprise" by Infor Global Solutions. This software is the WTF of all software.
Admin
"For example, out of the box, Visual Studio won't step into a catch block while debugging. You can debug catch blocks, but you have to explicitly set a breakpoint in them or they will be skipped entirely. There's an option to turn this behavior off, but it's hidden deep in the menus."
What? I use C# Visual Studio and it debugs catch blocks fine and I don't remember setting any secret hidden option...
Admin
Also, that wasn't mean to be a reply to Wolf...
Admin
The original reason for exceptions (when they were invented for c++) was to handle problems in constructors.
Other than that, the c way quickly degenerated into pseudo catch blocks, because all you did when you didn't like a return value was to GOTO to the label with the "exception" handler. The reason was, as others have pointed out that all the non-exception error handling code completely obscured the actual functionality you wanted to implement. Having the action happen as a side effect of an if isn't exactly conductive to making the intent of the code clear.
So, of course, exceptions can be abused, so can everything else. Java, with its checked exceptions is better at using them than c#, but they are neither inherently evil nor a cure-all.
Admin
Right, I once looked it up, and in Windows there can be like 19 different reasons why a file can be "found" but cannot be read. Checking for file existence is a rather poor check for readability.
Admin
The kind of mentality described in the article is what breeds:
on error resume next
Statements.
If you build a house of cards, don't be surprised if the slightest little thing causes it all to come tumbling down.
Admin
Thoughts:
Admin
+1
Don't catch exceptions where they occur unless you think you can add some value. For example, if a file is prone to be temporarily locked, catch the exception, and display a message to the user to try again in a couple of minutes. But if a file should be there (it is part of the application installation package), and it is not found, don't bother catching that exception. Let it bubble up to a global handler that logs the message for technical support, and then displays a message to the user "An unexpected error occurred - please contact technical support", and close the application.
Admin
I agree that exception handling is, all too frequently, abused. If you're querying a database or reading a file, you want exception handling. But DO NOT wrap every single line of your code in an exception handler that "repackages" the exception or swallows it. Don't do it. That's a surefire way to write craptastic code. If you are writing the end-user UI, and want to capture all exceptions to display a message and log something, that's one thing. If you are writing a library or API that is consumable by someone else, don't capture any exception unless you can do something with it (which is fairly rare) or it breaks the underlying functionality of the method call (like not being able to contact a database or access a file).
Admin
Geeze people, no! I can't believe the bad advice I see repeated every time exceptions are discussed. EXCEPTIONS ARE NO REASON TO ABORT A PROGRAM. Unless thrown from your startup routine, or they're hardware-raised ones like access violations.
And for the love of God, don't report them to the user as 'Derp! Please call offshore tech dummies.' Unless it's a high-security black-boxy web app. Exceptions give helpful info to humans, whereas error codes resolve no better than, for example, WinAPI's 'The parameter is incorrect.' Don't dump a call stack on the user, but do show the main message.
Handle 99% of them in your framework's winproc handler and your client/server comm loops. For the latter, I like to marshal exception messages over the wire; very sleek. Indeed, don't do special catches deep in the code unless you can specially handle special conditions.
Admin
I have always found that exactly one try-catch-finally block per function was pretty much perfect (sometimes in library functions with a limited set of conditions you can do manual checks instead but business logic is a different story). Unfortunately, way too many duhvelopers go to either extreme, suppressing every error and continuing to corrupt output or relying on some generic top-level handler that's beyond useless. Or both (especially love the suppress-and-rethrow-without-stack-trace pattern that leaves everyone staring at a screen that only says "oops, try again later"). And they will fight you to the ends of the Earth to keep the status quo.
Admin
Visual Studio absolutely steps into catch blocks if an exception fires. What it doesn't do by default is catch when an exception is actually thrown, you have to turn that on.
Admin
Corrupt file, I'll grant you should have error handling. FILE_NOT_FOUND should be handled in code, not a catch block
Admin
As stated above, In most situations you should only have a few try catch placed where they either can try to fix the problem, retrying to read a file a few times if files often are not done writing to when we try to read them or try re-fetching a webpage that often times out and where we cannot fix the page.
Many time these exceptions are unavoidable since Microsoft's code throws the exception.
You can also use the try catch to log the error and report a more meaningful message to the user.
C# have a good stack trace allowing you to see very accurately where the error was caused, in debug mode you even get line numbers, but in release mode you at least get the function name and all functions on the way there so for any unexpected exceptions you should be good with a single try catch around all code to catch any situation you really did not foresee.
That said, you should not use exceptions to handle flow control, like escaping from a function, that's lazy and costs performance compared to alternative solutions. and also makes the code very difficult to maintain and understand, much like goto (which still exists in C#)
Admin
Windows goes farther than that. Checking for readability doesn't even check for readability. If they detect that the file exists then they report that it can be read.
It's been a while but I think I was reading the source code of their _access() implementation.
https://msdn.microsoft.com/en-us/library/1w06ktdy.aspx
Admin
Seriously? You think the company described in this article didn't go belly-up?
Admin
" Exception to this: everything external (database calls, file IO, ...) should be guarded with exception handlers. "
This is ERP software, almost everything involves database calls. However, much of the time you want to catch then rethrow the exception after calling ROLLBACK
Admin
Well of course. Proper usage is the
Admin
Frankly, this isn't much of a WTF. While only one catch block is likely too few, the original proposal sounded like it may be too many, particularly when listing examples of the kinds of errors they were catching.
There are many types of exceptions - and the examples of a bad cast or an out of bounds index fall into this bucket - that really shouldn't be caught at anything other than a global catch-all that logs the error (hopefully including the stack trace). These are programmer errors, you don't catch them, you identify and fix the bug that allowed the exception to be thrown to begin with. You should never be trying to dereference a null reference, or reading beyond the bounds of an array.
There's another class of exceptions that are expected to happen from time to time - for example, a resource may sometimes be unavailable, a cancellable task may be canceled, etc. These are where you put specific catch statements to handle these conditions gracefully.
Lastly, there's a category of doomsday kind of errors - things that really shouldn't happen but when they do, it means the program is likely in an unrecoverably bad state, such as an out of memory exception. All you can do here is capture what debugging data you can and exit as quickly as possible.
Except for the "expected" class of exceptions, there should be very sparse need for catching exceptions, and none of the example exceptions in the article are things that should be caught.
Admin
30 years experience, or one years experience thirty times? You decide.
Admin
I kept imagining the boss of this startup to be Cobra Commander. He probably shouts, "Jussssst follow my ordersssss!" when people aren't perfect and don't code things perfectly the first time around while taking into account how the whole picture of code interacting together will function in real time like a bunch of machines.
Imo, TRWTF is yet another startup owner just trying to queef out software as fast as possible and having "experienced" developers not calling him on his stupidity after agreeing to work for him.
Admin
From the illustration I was mildly disappointed when it turned out the article wasn't about why Sonic 06.
Admin
Exception handling should be very rare. It's really only for things that naturally can fail. That is, external communication. There's a very small scope for internals exception handling. What you do instead if you let the application crash. Trying to handle exceptions for programmer error is a lost cause. 99.9% of exception handling for programmer errors fall into either you're in Zalgo land, letting it continue is merely propagating the error, something has gone wrong and the program has entered a state it wasn't made to handle, or you need to have the error checking everywhere for that category of error. Instead you should have strict modes and a sane level of sanity checks within the code. The only way to fix a case of inconsistent, invalid or unexpected states in software that come from programmer error is to throw an exception. Really, anything outside of exactly what you've programmed it to support should result in an exception being thrown.
Saying that there are some exceptions to that too but extreme exceptions. The software launching a rocket into space for example might not want to simply cease processing in the case of an unexpected condition. You would still probably propagate the error to some higher level of control though and potentially fail that overall level of work or fallback to a default/alternative mechanism.
Admin
"You cannot account for these without exception handling" - sure you can. Any single iOS or macOS program does exactly that. The examples that you gave would probably be running asynchronous code which ends by either calling a success block or a failure block. Sure you have error handling, but errors are not an exception. If they are treated as exceptions, that would make me worry very much that they won't be handled very well. Having a success block and a failure block means you will be devoting equal amounts of thought to each. It forces you to actually handle the problem beyond catching an exception.
Admin
The biggest WTF is this discussion. There is no universal pattern how to correctly use exception. It always depends on type of code you are working on. Sometimes there are multiple patterns how exception should be used even withing one application.
For those knights of "report and fail" approach, congratulation, you would kill Neil an Buzz on Moon.
Admin
Agreed.
Admin
The .NET standard library is too exception-happy. IMO, exceptions should only exist for programmer errors that could not be caught by the type system. Then, the single top-level exception handler is the correct way to deal with this in a production environment.
Any other "exceptional" circumstance, expected enough to have an exception defined for it, is not exceptional. It should not be an exception; instead, the operation should return a "result" type (OK, or Failed with reason). See Rust, Haskell, etc.
Admin
I would use exception handlers in all cases except in the exceptional case where the exception is on my list of exceptional cases to be non-exceptionally exception handled except when it's an exception to my list of exceptions and then................. and so on.
C'mon guys. Do whatever the fuck you want that works. There's no right or wrong. There is only what works. If you spend 8 hours de-mangling a once in a blue moon condition, HANDLE IT, so you or another need not spend 8 hours the next time.
Admin
That's even worse, since now you have to check a "success" boolean after every function call and your code now branches after every function call, and it requires all your code to know how to pass flags back up the call stack, and hopefully it makes it to the right place in the code that knows how to handle it. Exceptions are much more flexible and don't require the constant checking and passing around of error codes. An exception any where in the call stack will immediately bubble up to the exact place that can handle it with all the information it needs to handle the error.
Admin
The SNOBOL article was that-a-way ------------------------------------->
Admin
I understand we're probably discussing a number of different languages, but being mostly a Java guy (at least with respect to exceptions) I have to wonder: how do you communicate bad input to functions if you're not using exceptions? A magic return value? A class variable somewhere? (woh! maybe a static one? :o)
I am pretty sure I read, that exceptions, for instance in C (or perhaps it was C++) was introduced specifically to open up another way to communicate error data from a method. Before there were exceptions, your method would return a number if there was a problem, or 0, and in normal cases update pointers or inout variables, or whatever your language of choice could handle.
If there was an error, the system would say: An error of type 1 has occurred....
Or, maybe I should translate the "you should never use exceptions" to "you should never catch exceptions"... I don't know...
Admin
I stopped reading at the bit where VS wouldn't step into a catch. Because it's wrong. I've used VS since 2002 and it has never behaved that way. But thebit about Visual Studio being good for beginners makes me think the author just has an axe to grind with Microsoft.