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.