|
Most of these could be exceptions in some circumstances, but in other circumstances an app should check.
For example, usually I'd check and handle a file not existing, but if that file is a crucial resource for the app and the app cannot continue reasonably without it, that's an exception.
Except bad user input - that should always be checked.
In other words, there's an exception to every rule (except the bad user input one, but that's an exception to this rule).
(Edited to allow adding a bad attempt at a joke )
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I am spending a lot of time currently writing little utility applications for moving data about. I always run them through the debugger in VS so rarely put any try catch blocks in there as I want to jump straight into the debugger if any are thrown.
|
|
|
|
|
For me is a consistent way to handle errors.
My best-practice is to separate them into two groups: Technical and Business.
These two types are actually represented by two classes that inherit from Exception.
With this we can, on a higher level, decide how to notify the user.
Usually a TechnicalException will go to a "Contact the support" or "Try again later" kind of message, while a BusinessException will clearly notify the user what went wrong and what he must do to correct the issue.
I usually also like to class my exceptions with codes, HTTP style.
This helps me solve localization issues and simplifies logging.
Cheers!
|
|
|
|
|
Ditto. And I have also used the distinction between User-layer errors and system errors. A global error (exception) handler can then decide how to present the error - or log it, or pass it on.
Now, if only "exceptions" were named "structured error handling" instead then I believe we would have a more fruitful discussion. Truly exceptional events are so rare that it doesn't make sense to have a whole lot of machinery built into languages to handle them. E.g. if even out-of-memory is not a truly exceptional event - as it has been argued - then why bother having all that stuff built in to handle it ?
So - can we try to think of this as "structured error handling" instead ? And in that case I will stand firm and say that it makes perfect sense to apply it to all the examples listed.
And I say "apply it" - 'cause you should rarely, if ever, attempt to catch exceptions. Catching exceptions without re-throwing should only be done at the very top-level of your application. Otherwise, just pass it on.
|
|
|
|
|
..."Handled with exceptions". What does that even mean? Does it mean we use try...catch to detect the problems and fail gracefully? Or that we generate the exceptions and pass them on up? Or (in the case of user input errors for example) that we should rely on exceptions to report problems?
Because I catch some, throw some, and check user input to prevent exceptions happening.
So I had to go for "Which of the following issues are best handled using Exceptions? CListCtrl and LiquidNitrogen" because Bacon should be the Rule, not the Exception.
Waddayamean there isn't an option for that?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I'm also confused about what "handled with exceptions" means. So I just checked all of them.
Generally as a rule of thumb I catch ALL exceptions at the highest level possible to prevent the application to crash. There might be an occasional try-catch-block to handle specific cases and also the occasional exception I throw myself (e.g. during parameter validation).
I think exceptions are pretty useful to control the program flow in case where it doesn't go the way I expected or intended it to.
|
|
|
|
|
Nicholas Marty wrote: I'm also confused about what "handled with exceptions" means. So I just checked all of them.
I ended up checking all of them except User Input Validation. Invalid content there should always be expected, never exceptional, meaning that you should always check for it pre-emptively.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Well, as it was formulated as "Invalid data supplied by the user" instead of "user input validation" and I have no idea in which context this was meant to be, I still checked it.
Who is that "user"? An end user actually using your frontend? Then I agree to not use exceptions to validate the input. But there are other types of users. And an example where I actually used exceptions to validate input is a WCF Service where I throw FaultExceptions in case the user supplies invalid data.
|
|
|
|