Jump to content
Juan C.Cilleruelo

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

Recommended Posts

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 by Guest

Share this post


Link to post

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;

 

  • Like 3

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post
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? 

Share this post


Link to post

 

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".

Share this post


Link to post
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. 

Share this post


Link to post
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.

Share this post


Link to post
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.)

Share this post


Link to post
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'.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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. 

Share this post


Link to post

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.

Share this post


Link to post
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! :classic_laugh:

  • Haha 3

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×