I really hate this type of paranoia constructions. What do you think about?

[Juan C.Cilleruelo 12]

   try
      WriteLicenseData;
   except
     on exception do begin
        raise;
        Exit;
     end;
   end;

 

[Juan C.Cilleruelo 12]

If anyone has not noticed, the previous structure is, in code, equivalent to:

 

WriteLicenseData;

 

[Guest]

1. The Exit; will never execute, but LOC +1
2. catching exceptions only to raise them again is only for incrementing LOC counter

But that has nothing to with paranoia ... it is worthless at all

Edited December 14, 2018 by Guest

[Der schöne Günther 316]

That's not harmful, it's just unnecessary code. 

 

What really rustles my jimmies is something like this:

try
	doSomething();
except
	ShowMessage('There was an error');
end;

 

[dummzeuch 1505]

3 hours ago, Schokohase said:

1. catching exceptions only to raise them again is only for incrementing LOC counter

It creates a line to place a breakpoint, if you disable stop on exceptions in the debugger.

[David Heffernan 2345]

4 hours ago, dummzeuch said:

It creates a line to place a breakpoint, if you disable stop on exceptions in the debugger.

But how do you break there if you disable debugging? 

[dummzeuch 1505]

 

9 hours ago, David Heffernan said:

14 hours ago, dummzeuch said:

It creates a line to place a breakpoint, if you disable stop on exceptions in the debugger.

But how do you break there if you disable debugging? 

The option I was talking about is called "Notify on language exceptions".

[David Heffernan 2345]

2 hours ago, dummzeuch said:

 

The option I was talking about is called "Notify on language exceptions".

I know, but if you want to break on an exception, why would you disable that? Writing naff code instead of using the tools of the debugger is pointless.

 

My question was rhetorical. If you disable debugging, it would be odd to then jump through hoops to debug your program. 

[dummzeuch 1505]

1 hour ago, David Heffernan said:

I know, but if you want to break on an exception, why would you disable that? Writing naff code instead of using the tools of the debugger is pointless.

 

My question was rhetorical. If you disable debugging, it would be odd to then jump through hoops to debug your program. 

Sorry, to answer a rhetorical question (again), but:

There are types of exceptions I usually don't care about and are therefore disabled in the debugger, e.g. EAbort. Sometimes, if there is a problem with these in a particular part of the code, I want to catch them and follow the exception handling further up. But even then I don't want to enable them everywhere else. That's a possible use case for the above construct.

[Juan C.Cilleruelo 12]

Maybe, catch the exception with the intention of re-raise the same one, is useful for someone, but... the "Exit;" instruction too?

[dummzeuch 1505]

1 hour ago, Juan C.Cilleruelo said:

Maybe, catch the exception with the intention of re-raise the same one, is useful for someone, but... the "Exit;" instruction too?

The exit doesn't make sense, but it is quite possible that it is left from a previous version of the code that didn't re-raise the exception.

(Or it's just from somebody who didn't understand the way exceptions work.)

[Juan C.Cilleruelo 12]

11 hours ago, dummzeuch said:

The exit doesn't make sense, but it is quite possible that it is left from a previous version of the code that didn't re-raise the exception.

(Or it's just from somebody who didn't understand the way exceptions work.)

 

All the code is from somebody who didn't understand, absolutely, the way exceptions work.

 

This structure is not a punctual case in the code I'm revisiting, is a constant. Is on all the methods. I think that this type of wrong conception code is more than 30% of the whole code.

It's because I commented it like 'paranoid code'.

[David Schwartz 426]

In that case, I wouldn't call it "paranoid code". There are people who are taught that you want to employ certain practices to make your code "bullet-proof" or at least "safe". Unfortunately, they either weren't taught, or didn't understand, the reasons WHY or what's really going on.

 

I'm working on this huge code base right now and it's got lots of try ... except clauses throughout it. Unfortunately, in many places, the except clause simply logs the exception's standard error message to a log file then just goes wherever it goes. The log file is absolutely useless in this case, because there's insufficient information in the typical exception error message to allow you to figure anything out.

 

So we've got lots of nice code designed to safely capture exceptions and log them, but the information being logged is useless. And even worse (IMHO) is that the code makes no effort to recover!

 

Many if not most of these exceptions are the result of a try ... except block that I suspect was just wrapped around a huge block of existing code. No effort was spared to narrow down the scope of the exceptions. So there are potentially dozens of exceptions that could occur in many different places. The info logged in the file is useless because there are no line numbers, no variable names, no context information at all. 

 

And in most cases in THIS particular bunch of code, the logic could be easily adapted to recover from the errors if it did any useful amount of testing and validating things.

 

I mention this b/c we recently had to deal with one of the apps that started generating a ton of errors. They were all silently logged in the log file, and nobody had a clue anything was awry until a customer called and said there was a problem with some of their billings. We started looking through the log files and saw that there was a GPF occurring regularly that started one day a few weeks earlier. Nobody had a clue! And we stared at the errors in the log file scratching our heads trying to figure out what in the heck might be wrong. All we could tell was there was a GPF occurring in one of the units.

 

That's why I always lobby to include something like MadExcept with everything. This app hasn't been rebuilt in ages (until recently), so nobody even thought about configuring it in.

[Stefan Glienke 2002]

13 hours ago, David Schwartz said:

they either weren't taught, or didn't understand, the reasons WHY or what's really going on.

The term for that is Cargo cult programming

[Lars Fosdal 1792]

Crosses heart, spits over left shoulder, throws salt over the right one, all while repeating "Thou shall not goto".

[Stefan Glienke 2002]

@Lars Fosdal Goto where?

[Lars Fosdal 1792]

On 12/21/2018 at 4:01 PM, Stefan Glienke said:

@Lars Fosdal Goto where?

That is the core of the question, isn't it?

[Rollo62 536]

Goto: Where no man has gone before

[Rudy Velthuis 91]

On 12/14/2018 at 4:40 PM, Der schöne Günther said:

That's not harmful, it's just unnecessary code. 

 

What really rustles my jimmies is something like this:

try
	doSomething();
except
	ShowMessage('There was an error');
end;

 

Oh, I use that too, but only in simple test programs. So it all depends on where it is used.

[Der schöne Günther 316]

But I don't understand - Isn't that just destructive? It throws away the additional information the default exception dialog would have shown you. It displays a generic message which is not helpful. A simple

doSomething()

is just better.

[Dalija Prasnikar 1396]

15 minutes ago, Der schöne Günther said:

But I don't understand - Isn't that just destructive? It throws away the additional information the default exception dialog would have shown you. It displays a generic message which is not helpful. A simple

doSomething()

is just better.

I am sure your users will appreciate reading default exception message they cannot comprehend.

 

Of course, "There was an error" is not proper error message - but that is different discussion topic. 

[Sherlock 663]

@Dalija Prasnikar:The context was "simple test programs". No regular users around those...I hope.

[Der schöne Günther 316]

Exactly. For regular user applications, you hopefully have a global exception handler that turns an exception object into something readable for the end user. Translating computer speech to text that is shown on screen does not belong into the backend code for handling license data and whatnot.

[Dalija Prasnikar 1396]

2 hours ago, Sherlock said:

@Dalija Prasnikar:The context was "simple test programs". No regular users around those...I hope.

If I had a dime for every time some "simple test code" ended in production... 😋

[Bill Meyer 337]

3 hours ago, Dalija Prasnikar said:

If I had a dime for every time some "simple test code" ended in production... 😋

Then you would need a very large truck!