Some C# code that makes me sick...
-
Thankfully I have a robust constitution and delete it viciously... But I thought I should purge here for all to see! The kind of code below makes me sick to the bone... When I see it I need to immediately incinerate this try/catch never to be caught again!
try {
DoX();
}
catch (Exception ex) {
throw new Exception("Having problem Doing X!", ex);
}And don't give me the horseradish about "but they use this opportunity to do logging and stuff". I mean this exact code above! No additional stuff! :O And speaking of logging, I have seen such try/catch/logging being nested zillion of time resulting in zillion of log entry for one single exception... yuk... :sigh: All of that can surmised with this simple hypothetical dialog Q: (Newbye Dev) How do I throw an exception in case of exception? A: (Captain Obvious) Just don't catch the goddamn exception you donkey!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Thank you for your post. It got me thinking. Maybe I should place a try at each method's entry and a catch at each method's exit so as to add the method's signature and argument list to the exception message. A one line try at entry and a one line catch at exit doesn't offend my sense of aesthetics. Unfortunately as far as I know it would require knowing the types of exceptions thrown by each called method and I don't know how to do that w/o it being a pain in the rear. Perhaps this could be automated. I don't see why not. Something to cogitate on. For now though I have some hopefully exceptional code to write. - Cheerio
-
Thankfully I have a robust constitution and delete it viciously... But I thought I should purge here for all to see! The kind of code below makes me sick to the bone... When I see it I need to immediately incinerate this try/catch never to be caught again!
try {
DoX();
}
catch (Exception ex) {
throw new Exception("Having problem Doing X!", ex);
}And don't give me the horseradish about "but they use this opportunity to do logging and stuff". I mean this exact code above! No additional stuff! :O And speaking of logging, I have seen such try/catch/logging being nested zillion of time resulting in zillion of log entry for one single exception... yuk... :sigh: All of that can surmised with this simple hypothetical dialog Q: (Newbye Dev) How do I throw an exception in case of exception? A: (Captain Obvious) Just don't catch the goddamn exception you donkey!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.Datato add context if really really needed. https://docs.microsoft.com/en-us/dotnet/api/system.exception.data?view=net-5.0Maybe I, Maybe U, can make a change to the world!
-
Thankfully I have a robust constitution and delete it viciously... But I thought I should purge here for all to see! The kind of code below makes me sick to the bone... When I see it I need to immediately incinerate this try/catch never to be caught again!
try {
DoX();
}
catch (Exception ex) {
throw new Exception("Having problem Doing X!", ex);
}And don't give me the horseradish about "but they use this opportunity to do logging and stuff". I mean this exact code above! No additional stuff! :O And speaking of logging, I have seen such try/catch/logging being nested zillion of time resulting in zillion of log entry for one single exception... yuk... :sigh: All of that can surmised with this simple hypothetical dialog Q: (Newbye Dev) How do I throw an exception in case of exception? A: (Captain Obvious) Just don't catch the goddamn exception you donkey!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.
-
try catch statements should only be used in the UI/client layer, not in business layer or data layer - usually. you should ALWAYS log your exceptions to a database or file log without exception. you should not use try/catch/exceptions to control logic flow, whenever possible. my 2 cents. the code you referenced is crap IMHO. instead of re-throwing the exception, it should be logged, and handled gracefully and informatively for the end user.
-
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.Datato add context if really really needed. https://docs.microsoft.com/en-us/dotnet/api/system.exception.data?view=net-5.0Maybe I, Maybe U, can make a change to the world!
More times than I can count, I have seen debugging and fix time for a production issue cut from days to hours, or hours to minutes, because the appropriate runtime variables were added as name-value pairs to the exception's Data collection. That reduced time is gold to a software project during the full SDLC.
-
Thankfully I have a robust constitution and delete it viciously... But I thought I should purge here for all to see! The kind of code below makes me sick to the bone... When I see it I need to immediately incinerate this try/catch never to be caught again!
try {
DoX();
}
catch (Exception ex) {
throw new Exception("Having problem Doing X!", ex);
}And don't give me the horseradish about "but they use this opportunity to do logging and stuff". I mean this exact code above! No additional stuff! :O And speaking of logging, I have seen such try/catch/logging being nested zillion of time resulting in zillion of log entry for one single exception... yuk... :sigh: All of that can surmised with this simple hypothetical dialog Q: (Newbye Dev) How do I throw an exception in case of exception? A: (Captain Obvious) Just don't catch the goddamn exception you donkey!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
:omg:
Pete McNamee "True knowledge exists in knowing that you know nothing."
-
Thankfully I have a robust constitution and delete it viciously... But I thought I should purge here for all to see! The kind of code below makes me sick to the bone... When I see it I need to immediately incinerate this try/catch never to be caught again!
try {
DoX();
}
catch (Exception ex) {
throw new Exception("Having problem Doing X!", ex);
}And don't give me the horseradish about "but they use this opportunity to do logging and stuff". I mean this exact code above! No additional stuff! :O And speaking of logging, I have seen such try/catch/logging being nested zillion of time resulting in zillion of log entry for one single exception... yuk... :sigh: All of that can surmised with this simple hypothetical dialog Q: (Newbye Dev) How do I throw an exception in case of exception? A: (Captain Obvious) Just don't catch the goddamn exception you donkey!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.
-
Because you haven't imagined the horror to its full extent yet!!!
void Method_1()
{
try {
Method_2();
} catch (Exception ex) {
// logging maybe?
throw new Exception("Method_2", ex);
}
}
void Method_2()
{
try {
Method_3();
} catch (Exception ex) {
// logging?
throw new Exception("Method_3", ex);
}
}
void Method_3()
{
try {
Something();
} catch (Exception ex) {
// logging again?
throw new Exception("Something", ex);
}
}I'd say how about that?
void Method_1()
{
Method_2();
}
void Method_2()
{
Method_3();
}
void Method_3()
{
Something();
}or that
void Method_1()
{
try {
Method_2();
} catch (Exception ex) {
// logging perhaps?
throw new Exception("Method_2", ex);
}
}
void Method_2()
{
Method_3();
}
void Method_3()
{
Something();
}instead!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Thankfully I have a robust constitution and delete it viciously... But I thought I should purge here for all to see! The kind of code below makes me sick to the bone... When I see it I need to immediately incinerate this try/catch never to be caught again!
try {
DoX();
}
catch (Exception ex) {
throw new Exception("Having problem Doing X!", ex);
}And don't give me the horseradish about "but they use this opportunity to do logging and stuff". I mean this exact code above! No additional stuff! :O And speaking of logging, I have seen such try/catch/logging being nested zillion of time resulting in zillion of log entry for one single exception... yuk... :sigh: All of that can surmised with this simple hypothetical dialog Q: (Newbye Dev) How do I throw an exception in case of exception? A: (Captain Obvious) Just don't catch the goddamn exception you donkey!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.
-
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! :)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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! :D
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Thankfully I have a robust constitution and delete it viciously... But I thought I should purge here for all to see! The kind of code below makes me sick to the bone... When I see it I need to immediately incinerate this try/catch never to be caught again!
try {
DoX();
}
catch (Exception ex) {
throw new Exception("Having problem Doing X!", ex);
}And don't give me the horseradish about "but they use this opportunity to do logging and stuff". I mean this exact code above! No additional stuff! :O And speaking of logging, I have seen such try/catch/logging being nested zillion of time resulting in zillion of log entry for one single exception... yuk... :sigh: All of that can surmised with this simple hypothetical dialog Q: (Newbye Dev) How do I throw an exception in case of exception? A: (Captain Obvious) Just don't catch the goddamn exception you donkey!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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. `FileNotFoundException`s 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.
-
Thankfully I have a robust constitution and delete it viciously... But I thought I should purge here for all to see! The kind of code below makes me sick to the bone... When I see it I need to immediately incinerate this try/catch never to be caught again!
try {
DoX();
}
catch (Exception ex) {
throw new Exception("Having problem Doing X!", ex);
}And don't give me the horseradish about "but they use this opportunity to do logging and stuff". I mean this exact code above! No additional stuff! :O And speaking of logging, I have seen such try/catch/logging being nested zillion of time resulting in zillion of log entry for one single exception... yuk... :sigh: All of that can surmised with this simple hypothetical dialog Q: (Newbye Dev) How do I throw an exception in case of exception? A: (Captain Obvious) Just don't catch the goddamn exception you donkey!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.
-
Thankfully I have a robust constitution and delete it viciously... But I thought I should purge here for all to see! The kind of code below makes me sick to the bone... When I see it I need to immediately incinerate this try/catch never to be caught again!
try {
DoX();
}
catch (Exception ex) {
throw new Exception("Having problem Doing X!", ex);
}And don't give me the horseradish about "but they use this opportunity to do logging and stuff". I mean this exact code above! No additional stuff! :O And speaking of logging, I have seen such try/catch/logging being nested zillion of time resulting in zillion of log entry for one single exception... yuk... :sigh: All of that can surmised with this simple hypothetical dialog Q: (Newbye Dev) How do I throw an exception in case of exception? A: (Captain Obvious) Just don't catch the goddamn exception you donkey!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Even worse is when they don't wrap the original exception in the new exception, but throw away any knowledge of the error.
-
Thankfully I have a robust constitution and delete it viciously... But I thought I should purge here for all to see! The kind of code below makes me sick to the bone... When I see it I need to immediately incinerate this try/catch never to be caught again!
try {
DoX();
}
catch (Exception ex) {
throw new Exception("Having problem Doing X!", ex);
}And don't give me the horseradish about "but they use this opportunity to do logging and stuff". I mean this exact code above! No additional stuff! :O And speaking of logging, I have seen such try/catch/logging being nested zillion of time resulting in zillion of log entry for one single exception... yuk... :sigh: All of that can surmised with this simple hypothetical dialog Q: (Newbye Dev) How do I throw an exception in case of exception? A: (Captain Obvious) Just don't catch the goddamn exception you donkey!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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".
-
Thankfully I have a robust constitution and delete it viciously... But I thought I should purge here for all to see! The kind of code below makes me sick to the bone... When I see it I need to immediately incinerate this try/catch never to be caught again!
try {
DoX();
}
catch (Exception ex) {
throw new Exception("Having problem Doing X!", ex);
}And don't give me the horseradish about "but they use this opportunity to do logging and stuff". I mean this exact code above! No additional stuff! :O And speaking of logging, I have seen such try/catch/logging being nested zillion of time resulting in zillion of log entry for one single exception... yuk... :sigh: All of that can surmised with this simple hypothetical dialog Q: (Newbye Dev) How do I throw an exception in case of exception? A: (Captain Obvious) Just don't catch the goddamn exception you donkey!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.