|
I have seen too. Sometimes adding context is helpful (most of the times it doesn't). If we need to add context, you can use Exception.Data to add context if really really needed.
https://docs.microsoft.com/en-us/dotnet/api/system.exception.data?view=net-5.0
Maybe I, Maybe U, can make a change to the world!
|
|
|
|
|
If they logged, or added something useful to the new Exception (let's say there were parameters to this method, and the exception method was more like ["Having trouble doing X for " + param.ToString()]), then maybe I could see an excuse for a catch and throw.
As you show it, you're right to burn it to the ground.
|
|
|
|
|
Pete McNamee
"True knowledge exists in knowing that you know nothing."
|
|
|
|
|
But you have to do it that way for the super catch block to work. Excuse the syntax due to phone!
Catch (Exception ex){
If (ex.getMessage() == “Having problem doing X”)
Else If (ex.getMessage() == “Having problem doing Y”)
Else If (ex.getMessage() == “Having problem doing Z”)
}
Oh no, I forgot the exclamation mark and a default “catch” all.
|
|
|
|
|
Hahah! 
|
|
|
|
|
Been programming C/C++ for 26 years...never once used a try/catch (I think it's more humane to let the abortive program die and analyze the carcass...I mean the core dump).
And letting videogame consoles die in the middle of a game is more exciting than praying it's not having exceptions.
|
|
|
|
|
Wow.. metagaming here! 
|
|
|
|
|
IMHO, the correct answer to "How should I handle exceptions?" is "Do Not." ("Unless you know how to recover from a specific exception." (e.g. FileNotFoundExceptions are easy to deal with. However, if you try to handle things like DivideByZeroException, OutOfMemoryException, or StackOverflowException, you're pretty much attached by an inclined plane wrapped helically around an axis.)
Also (I might catch (pun intended) a lot of flak for this):
- re-throwing exceptions should be avoided like the plague, as doing so can potentially cause a single exception to be logged multiple times. Unfortunately, of the
async/await (i.e. things in the System.Threading.Tasks namespace) re-throw a lot, which leads to a lot of noise and distractions while debugging). - a
catch { ... } block is the wrong place to log exceptions.
A better alternative is use [Exception Filters] for logging. For example:
try {
Foo();
}
catch(SpecificException ex) when (ex.Log()) {
}
(Where .Log is an extension method that always returns false).
An even better alternative is to avoid logging exceptions in catch blocks or exception filters altogether. I am glad that it was decided not to remove the System.AppDomain class in .NET Core and .NET 5+ for this very reason: you can use the [AppDomain.FirstChanceException] and [AppDomain.UnhandledException] events as the one (erm... OK, two) place(s) to log all exceptions. You can even get fancy and add something to the Exception.Data dictionary in those events to avoid logging the same exception multiple times. However, in order for this to be useful, exceptions should not be re-thrown in order to ensure the logging of complete stack traces.
Eagles my fly, but weasels don't get sucked into jet engines.
|
|
|
|
|
The one variant I think can be useful involves an opaque abstraction, which defines a set of its own exceptions, framed solely in terms of that abstraction. Any opaque abstraction is violated when an unanticipated implementation failure occurs, as it cannot be framed in terms of the abstraction. The best the abstraction can offer is a "weasel words" exception that chains the original cause, shamefully "exposing its call stack to all the world". Recovery code can log the cause for the support ticket.
The posted code, of course, is simply gross. It adds nothing, hides nothing, and loses everything that might be of support value, while working hard at looking lazy. Doing nothing would be far lazier and far more effective.
|
|
|
|
|
Even worse is when they don't wrap the original exception in the new exception, but throw away any knowledge of the error.
|
|
|
|
|
I've recently written something similar, except (ok, that's a bad pun) this all is wrapped in a try-catch-log within the main application logic loop, meaning my middle layers often catch low-level exceptions and forward them. I.e. when my HAL throws a "Don't receive any data"-exception, my middle layer catches it and throws it as "Target device sends no data" for the high-level main loop to catch.
That of course is a different situation. You clearly said that's it and nothing additional. Come to think of it, that's another example for "patterns aren't bad, but they can be put to bad use".
|
|
|
|
|
While I agree with everyone's comments I would even go so far as to propose that (in the code you showed) that DoX detect its own error and return a meaningful result that cuold be acted on programmatically.
And to protect against THAT going wrong there would be a try/catch at the outermost level.
|
|
|
|
|
|
A man, a plan, a canal, Panama!
|
|
|
|
|
So disappointing. I was waiting for a palindrome with the name "Suez"...
Software Zen: delete this;
|
|
|
|
|
Current event:
You need to update it to include the sunk boat blocking a one lane section.
|
|
|
|
|
I was going to, but that ship has sailed.
|
|
|
|
|
*Aibohphobia kicks in* 
|
|
|
|
|
Straw! No too stupid a fad, I put soot on warts.
|
|
|
|
|
I like this one
Satan oscillate my metallic sonatas
|
|
|
|
|
Madam, I'm Adam.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
Visa will now accept "dollar-backed" cryptocurrency.
In other words, it won't fly unless you factor in the dollar ... you know, the "obsolete" currency.
I'd go for a salami-backed cryptocurrency ... which inevitably would still be priced by the dollar.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Unsurprising, as Visa statements are in dollars. If they took payment in anything else, they'd have to deal with the equivalent of forex exposure. But there are "stablecoins" pegged to the dollar, and even the Fed wants to float them, so Visa is just prepping for bigger days ahead.
The dollar isn't obsolete. Nor would seashells be obsolete, if I told you that you had to pay my bill--for very few services rendered--in seashells. And that if you didn't pay with them, some of my "boys" would pay you a little visit. Meanwhile, on the side, I'm creating seashells at will and giving them to my toadies.
But hey, back in the day I'd definitely have gone for a salami-backed crypto too! As long as it was good salami, which most of them aren't. I lived in Dallas for 12 years, and you have no idea how long it took me to find decent salami and rye. There are vast wastelands in the US that have no concept of anything like Dimpflmeier's rye or Piller's salami. And it ain't just TX. NH and CA, same shite.
|
|
|
|
|
Many years ago in a land far east of where I now live, when I was a very small child, my mother would make me "buy" sodas and other snacks from her ":Little Brown Chest®" cooler with sea shells.  A soda might be six clam shells (they were plentiful), while a small bag of potato chips might be three conch shells. She was teaching me about nature and economics, and how to count.
__________________
Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now.
© 2009, Rex Hammock
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
