|
Is buzz-kill a fly swatter?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Ah - as stinging pun, but let's bee sensible so we get moth responses that ant too cynical.
Note: if it's on the web, before long the buzz will be killed.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
No. It's one of these.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I thought buzz-kill was Narcan.
/ravi
|
|
|
|
|
* Other medications are available, including generic Naloxone Hydrochloride with the same or similar efficaciousness at a lower cost point.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
catch (Exception)
Look, if you're going to catch an exception, at least give it a variable so in the debugger I can see what the exception is. 
All because someone doesn't want to see "'ex' is declared but never used." Well, use it, FFS.
Latest Article - A 4-Stack rPI Cluster with WiFi-Ethernet Bridging
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
I often do this to avoid the warning:
catch (Exception ex)
{
if (ex != null) {}
}This way, if I'm debugging, I can always examine it, even if I ignore it in the code. I'm often called out for doing this in some of my articles here.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
It's kiddie code; the "politically correct" version of: ON ERROR GOTO <endlabel>
(btw: there's lots of that in public git code)
Message Signature
(Click to edit ->)
|
|
|
|
|
"But I don't C-A-R-E what the Exception is, I'm just required put it in the code. Gah!"
To be read as whiny as possible.
|
|
|
|
|
|
cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
modified 22-May-19 0:30am.
|
|
|
|
|
Dont fizzle with such details. Important is that the app doesnt crash for now and doesnt spit on the logs or debugger.
Never heard of "agile" development style? 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
KarstenK wrote: Dont fizzle with such details. Important is that the app doesnt crash for now
Famous last words.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
"We fix it in the next sprint." says my boss 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Which brings us to another philosophical question: What to do with an exception that does not hurt, can't be prevented, nor meaningfully handled?
Sweep it under the rug, like it is done here? Maybe there is not much you can do about it once it has happened. Maybe it's not harmful, but then you would be using exceptions as a means to control program flow. That's not a good idea.
I would say that it's better to use such Pokemon exception handlers to catch and log all unexpected exceptions and log them away. Once in a while someone should read these logs and take a look if this exception can be prevented or handled. Sweeping this under the rug is just lazy.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: What to do with an exception that does not hurt, can't be prevented, nor meaningfully handled?
In most cases, the "expected exception" will be a more derived type than System.Exception. The catch block should catch that derived type, and have a suitable comment to explain why it's ignoring the exception.
Of course, there are always exceptions. Back in the early days of .NET, certain invalid input passed to the ColorTranslator.FromHtml[^] method would deliberately catch a FormatException and wrap it in a System.Exception, which made it painful to catch. (Especially as this pre-dated C#'s access to exception filters, and before C# stopped handling corrupted state exceptions[^] by default.)
I reported the bug on the Connect site (which was "retired" last year[^], deleting all of the information collected there). I was told that it couldn't possibly be fixed, because that could be a breaking change. They couldn't even change it to wrap the FormatException in another FormatException, in case somebody had written code which relied on the exact exception type. 
Thankfully, they seem to have come to their senses and fixed it sometime around .NET 2.0.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
JSOP's approach is one.
We have special handlers in our app's logger that handle exceptions, we can flag in config if they should be shown or not
veni bibi saltavi
|
|
|
|
|
JSOP's code shown above sweep it under the rug. I can't see why this should the right approach. It would be better to add a "throw;" after his "warning elimination code fragment" or then log the excepiton.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
I've learned, to my chagrin, that some very commonly used libraries (looking at you EF) will do the unfathomable and use exceptions for flow control. There's not much option in those cases.
As in all things, context matters :/
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
CodeWraith wrote: What to do with an exception that does not hurt, can't be prevented, nor meaningfully handled?
A question whose only possible answer is a self-contradictory paradox is a conundrum.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
CodeWraith wrote: What to do with an exception that does not hurt, can't be prevented, nor meaningfully handled?
First I insure that I am catching that exception and no other. Not 'Exception' and not other generics such as ones like 'HttpException' which can wrap other types. I might need to catch something like HttpException but then drill down to the root cause to insure I have the exact one.
Then I put a comment in that specifically says it is ignored along with a reason why it is ignored.
Sometimes I log it but with the Debug(), or Trace() method so it allows someone to turn it on if needed.
|
|
|
|
|
To be fair, general purpose code doesn't care what the error is in the bulk of cases. It wants to clean up and pass it up the chain to something that has some problem domain understanding of what is going on.
Of course in my case I will be adding to the exception stack trace before rethrowing so I have to have it available anyway, though I'm not actually looking at it.
You can obviously use conditional compilation if you just want to have it available for debug builds and not otherwise.
Explorans limites defectum
|
|
|
|
|
Dean Roddey wrote: To be fair, general purpose code doesn't care what the error is in the bulk of cases. It wants to clean up and pass it up the chain to something that has some problem domain understanding of what is going on.
In that case, you should be using exception-safe programming techniques. Never catch and rethrow an exception "just to clean up"; that's what stack unwinding is for.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
But I just said why I do it sometimes. It's to get a stack trace. That's a very, very useful purpose for it. It's saved my butt more times than I can count to figure out why something happened in the field. It's not at every little call along the way, but the important points that let me know where something was happening.
Otherwise I am using exception safe programming. Well, almost all of the time. There are exceptions to every rule sometimes. You aren't always dealing purely in a C++ world if you write low level code.
Explorans limites defectum
|
|
|
|
|
I would really appreciate hearing more about this !
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
