|
Wordle 326 5/6
⬜⬜⬜🟨🟨
🟨🟨🟨⬜⬜
⬜🟩🟩⬜🟩
🟨🟩🟩⬜🟩
🟩🟩🟩🟩🟩
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wordle 326 4/6
⬜⬜⬜⬜🟩
⬜🟨🟨⬜🟩
🟨🟩⬜⬜🟩
🟩🟩🟩🟩🟩
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 326 5/6
🟨⬜⬜⬜⬜
🟨⬜⬜⬜🟩
🟨⬜⬜⬜⬜
⬜🟩⬜🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Funny I went with this word
Wordle 326 4/6*
⬛⬛⬛🟨⬛
⬛🟩⬛⬛🟩
🟨🟩🟩⬛🟩
🟩🟩🟩🟩🟩
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Wordle 326 6/6*
⬜⬜⬜⬜🟩
⬜🟩⬜⬜🟩
⬜🟩⬜⬜🟩
⬜🟩⬜🟨🟩
🟨🟩⬜⬜🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 326 5/6
⬛⬛⬛⬛🟩
🟨⬛⬛🟨🟩
⬛🟩🟩⬛🟩
🟨🟩🟩⬛🟩
🟩🟩🟩🟩🟩
Get me coffee and no one gets hurt!
|
|
|
|
|
Wordle 326 4/6
🟨🟩⬜🟨⬜
🟨🟩🟩⬜⬜
⬜🟩🟩⬜🟩
🟩🟩🟩🟩🟩
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
I finally read the Register article on the so-called "Visual Basic 7" and of course it referenced the infamous On Error Resume Next command (also found in Classic ASP).
While that can lead to bad programming practices, the devil's advocate in me asks how is it any different/worse than the C# code below, or are they both frowned upon?
try
{
SomeCommandWithRiskOfFailure();
}
catch (Exception ex)
{
}
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Much worse: it's the equivalent of this:
try { DoSomething(); }
catch {}
try { DoSomething1(); }
catch {}
try { DoSomething2(); }
catch {}
try { DoSomething3(); }
catch {}
try { DoSomething4(); }
catch {}
It discards errors with no hope of telling if they ever occured, no debug to find out what failed or why, and worse, it's hidden in a single line of code that could be pages away from the faults. So if you just look at the "relevant code fragment" you have no idea that every problem is being swallowed and ignored.
On Error Resume Next is a good reason why VB should just be banned ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
True, but there are infrequent cases where the error condition truly is inconsequential.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Yes, and for those it's a good idea to put an "empty" try-catch around the code which will fail (or better, log it in a catch block).
Just being able to go "my code is right: look no errors" by putting On Error Resume Next right at the top of your code is horrific!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
On Error Resume Next is cleaner in these situations.
|
|
|
|
|
I agree, though I seriously doubt that's the reason any programmer worth his salt would use it.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
I have several times written code that was greatly simplified by explicitly ignoring errors after 'optional' operations.
A trivial example: If a personal user profile is available, use it to initialize the environment. If it is not, it really doesn't matter why not (in some environments, it might matter, but not in my cases). Otherwise, if an installation default profile is available, use that. If not, ignore the reason why it is not available, and use a hardcoded default profile. The application comes up running; that's the important thing for the user. Failing startup with a complex explanation that a user won't understand anyway is far less satisfactory.
For a first-time user, there will be no user profile; it is created from the first or second fallback. Defining an installation default profile is optional (and for a PC with a single user, it doesn't make sense), and setting it up requires far more understanding than from a first time user.
The #1 reason why the two first steps may fail is "It hasn't been created yet". I have not yet experience any other reason that a first time user would be able to fix even if the error message was displayed.
When the user exits the application, the personal profile is saved. Now, thorough checks are made. If there are conditions making that impossible, it will probably reveal the reason why the startup reading of the profile (which should have been there - the user is a returning one) failed. This happens very rarely, and doesn't bother the first time user. I have never experienced any case where reading a profile would fail but writing would succeed for any other reason than that it doesn't exist and will be created. So any other problem will be detected - without stopping the user from doing his work (although under a default profile).
You might argue: But for your own purposes, you should log the problem, even if you don't display the error to the user. That log would, in 99,9% of all cases, tell me: Reading user profile failed because this is a first-time user. Reading installation default profile failed because no installation default profile has been created. Well, I know that! I don't need a log file to tell me! For other failure reasons, the error report from saving the user profile will be good enough.
This reading of a user profile is one of three or four cases of "See if you can do the operation. If you cannot, it isn't a big deal - maybe even expected - so don't bother the user with it". Another case that comes to mind: At startup, looking for a saved list of uncompleted tasks for this user: If a task list is found, it is presented. If none is found, for whatever reason, it is not presented. If the user expected a task list and sees none, the documentation tells of possible reasons. The normal case is of course that there are no unfinished tasks, and failures to read the task list is not of interest to anyone.
I do not feel that I am doing a programming crime when I program in this style. (But then, I am also very fond of explanatory comments, so I always explain in the code why all errors are ignored.)
|
|
|
|
|
OriginalGriff wrote: It discards errors with no hope of telling if they ever occured,
What I do in this scenario is create a ResponseDto object and add a List<exception> to it so that all my methods return that Dto object with any exceptions. That way you can handle the exception at the top of the call stack.
My preference is to only use Try/Catch in the UI/front end if possible and not in the middle tier or supporting code libraries.
|
|
|
|
|
On Error Resume Next has a place. I have found it makes for cleaner code in situations where you really don't care if each statement completes error free or not, such as in clean up code before an application terminates. It's certainly cleaner than a slew of repeating try { Statement } catch {} blocks.
|
|
|
|
|
On Error Resume Next is far worse than the empty catch block.
In VB, the code will keep trying to execute line after line of code, even if they all fail, until the On Error is rescinded by another On Error line. This can lead to data loss if not carefully managed.
You also lose all of the error information on the original failure and the error handling model doesn't lend itself to the easy logging of errors.
An exception in a try block will simply stop executing that code and jump straight to the empty catch block, then a finally block (if supplied.)
Even if the catch block doesn't do anything to recover from an exception, you can at least still easily add code to log the error and other metadata in one place.
|
|
|
|
|
Which means that semantically and execution sequences the two options are different.
|
|
|
|
|
If you make any piece of software idiot proof, only an idiot will be willing/able to use it.
|
|
|
|
|
What! - The goal of any decent developer is to make their software idiot proof, that does not mean nagging them to confirm every step they take it is to catch and deal with all the edge cases and errors that occur.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Between your post and your sig, it sounds like you have a large chip on your shoulder about language constructs that allow goto and related, unstructured behaviors.
I'm not trying to start an argument, but I'm curious: why is that?
Software Zen: delete this;
|
|
|
|
|
LOL There's no chip on my shoulder, you're reading way too much into it. I just notice opinions and positions on matters that seem contradictory to me and often point them out.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
TNCaver wrote: is it any different/worse than the C# code below
I wouldn't use the word 'worse' as they are both perfectly legitimate ways of dealing with either expected or unexpected errors.
Judging by your sig, you already know this, but I can appreciate livening up the conversation here with a flame war. 
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
Honest, I wasn't trying to start a war! 
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
