|
Thick as a brick. 
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
Quote: But your new shoes are worn at the heels and
Your suntan does rapidly peel and
Your wise men don't know how it feels to be thick as a brick.
New version: WinHeist Version 2.1.0
My goal in life is to have a psychiatric disorder named after me.
I'm currently unsupervised, I know it freaks me out too but the possibilities are endless.
|
|
|
|
|
Or inexperienced developers!
|
|
|
|
|
If I had seen them coming, I would have handled this case before any exception would be raised. And when an exception comes, it will be logged. In most cases the current operation will also be aborted. Often the code to recover and continue after an error gets far more complicated than what it is worth.
The second and more important part is what you do with the log entries.
If the error is avoidable (like checking for null references), then you can turn the unexpected error into an expected and handled case. In the future there will be no more exceptions because of this.
In other cases you may be able to avoid the error by handling it in some way. You may, for example, wait a short time and retry a few times when a resource is temporarily blocked.
Last, there are the cases you can't do anything about. They are certainly unexpected. Why would you try to access something while expecting it not to work? Whatever has happened, it took place outside of your application and usually without prior notice. All you can do is to document the events in your log.
Proper testing can eliminate most of the first two types, leaving only the third. Exceptions are fine to assure that errors are logged and not swept under the rug. Then see to it that all errors appear only twice in the logs: For the first and the last time.
Only for the validation of user inputs I would use a more interactive approach than exceptions and logging. Actually, I don't see failed validation as an error. To me it's more a form of application logic that iterates over the user submitting input and validating it until it meets the requirements, whatever they may be. It's not unexpected, nor is this exceptional.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
