Have you ever wondered why ocasionally you can find some code along the lines of:

try
{
    SomeFancyThing();
} 
catch 
{
    throw;
}

On the face of it, it is a noop. It doesn’t wrap the exception into a new, more likable, one. It doesn’t prevent propagating of the exception. It doesn’t even log the exception. So, it does the same (ok, it also slows the execution down a little bit) as just writing

SomeFancyThing();

However, when lines of code are taken into account, things change dramatically. Instead of one line code, there is eight… 🤔 So, if productivity is measured by contributed LoC one can dramatically improve productivity by using this approach.

More weirdness

Worse, ofcourse, are

try
{
    SomeFancyThing();
} 
catch 
{
    
}

and

try
{
    SomeFancyThing();
} 
catch (Exception e)
{
    throw e;
}

In first example, at least log the exception so you know something bad happened. In second, stack trace is destroyed.

And still more

try
{
    SomeFancyThing();
} 
catch (Exception e)
{
    throw new MyFancyException(e.Message);
}

I have a gut feeling this somehow originates from Java. Or it’s forced by some team agreement on wrapping all exceptions. Then at least make it

throw new MyFancyException(e);

when throwing to preserve the original exception. You’ll thank yourself later.