|
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
|
|
|
|
|
catch (Exception shït_from_Marc_for_not_declaring_an_exception_variable)
Happy now? 
Software Zen: delete this;
modified 21-May-19 13:12pm.
|
|
|
|
|
Gary Wheeler wrote: Happy now?
I'll have to do that next time! Great idea!
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 expected to see a debate on naming conventions: underscores vs. Pascal case vs. camel case.
Software Zen: delete this;
|
|
|
|
|
Don't tell them about #pragma warning disable
|
|
|
|
|
Another example of a discussion that could have lasting value for CP members if it were a discussion on the C# language forum.
A 'catch without a 'throw is a homeless kitten 
Now, go ahead, report me for posting a code sketch: I'll wear the scars with pride 
using System;
using System.Runtime.CompilerServices;
using System.Text;
namespace YouMama
{
public static class MotherOfAllExceptionHandlersExtensions
{
public static string ThrowToMama(this Exception ex, bool doLog = true,
[CallerMemberName] string yoName = null,
[CallerFilePath] string yoFilePath = null,
[CallerLineNumber] int yoLine = -1)
{
StringBuilder sb = new StringBuilder();
string log = sb.ToString();
if (doLog)
{
Logger(log);
}
return log;
}
public static void Logger(string data)
{
}
}
}
private void button1_Click(object sender, EventArgs e)
{
int y = 1;
try
{
int x = 1 / (y - 1);
}
catch (Exception ex)
{
ex.ThrowToMama();
}
}For an in-depth overview of C# > 5 new Exception handling features by Michaelis: [^]
«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 4:03am.
|
|
|
|
|
Exception handling is not something that can be done generically. Especially at the 'Exception' level.
In certain cases one might generalize exception handling but only within the limits of some specific idiom. For example a specific inheritance model might provide a generic handler in the base class, but even then it should be considered as a convenience rather than as an absolute.
And generalizing logging is not going to work either. For example for DB api calls logging a primary id might be a good idea, while with a web API call logging the url is probably needed. There are a lot of variations even within those.
Not to mention that logging libraries seem to provide calls that support general purpose logging including exceptions so that would seem to do what that code does.
Far as I know the above would be true for all languages that throw exceptions. It is true for java, c# and c++.
|
|
|
|
|
Depending on how the debugger is set, it will display the exception anyway, before it's caught.
|
|
|
|
|
Is it really so difficult to add a variable name and recompile one file?
Not giving a name is correct usage if you don't plan to use the variable.
If you wanted to know what the exception was, the correct action is to do something in the handler like log the exception.
|
|
|
|
|
My standard practice is to name the exception, then add runtime variables (such as method parameters) to the data collection, then either log or throw to be logged higher in the stack.
My logger DLL (a thread-safe, high-performance singleton) checks for the Data collection in an exception and logs any data it finds in the name-value pair collection. Great info for debugging.
Example:
catch (Exception exUnhandled)
{
// String parameter
exUnhandled.Data.Add("param1", param1 ?? "NULL");
// Non-nullable type parameter
exUnhandled.Data.Add("param2", param2.ToString());
throw;
}
|
|
|
|
|
Agreed.
catch (Exception ex) {
string tmp = ex.Message;
}
Problem solved all 'round.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Yes, you appear to have solved the problem of how to create a string variable that will be unusable outside of the 'catch block.
«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
|
|
|
|
|
Which is the solution Marc asked for in the OP, n'est-ce pas?
Quote: 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.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
TNCaver wrote: Which is the solution Marc asked for in the OP, n'est-ce pas?
Oui 
«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
|
|
|
|
|
Marc Clifton wrote: 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
At least in the domains in which I work if you "need" to see the exception in a debugger then you "must" log it. Which means there would always be a variable.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
