Recent

Author Topic: Static code analysis  (Read 16423 times)

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 9085
  • FPC developer.
Re: Static code analysis
« Reply #15 on: January 24, 2015, 09:35:50 pm »
The question is are exceptions - exceptional?
The exceptional problem is running out of memory. In most cases the handler would attempt to save the existing data (without allocating more memory for operation) and terminate the program.

But if a file cannot be opened, is it an exception? or is it an possible and expected and behavior of the environment? and if it's the possible and expected, should the exception be risen? Exceptions raising/handling are quite expensive, compared to a classical function result processing.

(It is in a statically compiled language.  JITs might lighten that load since all exceptions of a trace might be known due to throws statements +a few language ones)

But yes I agree. One should allow exceptions to play out their strengths (error handling in deeply nested call structures that can't be dealt with locally). That also means if it can be dealt with locally like a trystrto* function etc, it is better to do so. At least IMHO.

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2562
    • havefunsoft.com
Re: Static code analysis
« Reply #16 on: January 24, 2015, 11:12:56 pm »
If a file cannot be opened, it is not expected but it is possible and then exceptions are a good way to handle it.
In this specific case handling not opened file should be part of an algorithm these days. For a simple reason of multi-task operating system. The file could exist, but was locked by some other application.

As you know you can define different types of exceptions and handle only some of them in the try-except block. It is a very flexible system.
Yes, but in this case the handling exceptions is no better than error codes processing. I'd need to have a separate handler code for each exception type I expected and a generic one, for the ones I don't.
The difference from the error code processing, is that exception handling would be out-side of the algorithm in the catch block, with no way to return back.

Exceptions can be used for any kind of errors. For example your method is passed a parameter which is not in the list of allowed values, then you raise an exception which is handled higher in the call stack.
As you know you can define different types of exceptions and handle only some of them in the try-except block. It is a very flexible system.
..I am quite amazed you want to go back to the clumsy C-style error handling.
Let me add Google's reasons then. It's all nice with Exceptions, but as long as you're working within your language. As soon as one is trying to handle exceptions from another language - a problem starts, since binary exceptions are different. Thus creating a library might be problematic.
some examples: DLLs generated exceptions are not very well handled in Windows code. ObjC exceptions are not handled in ObjPascal (yet?) and vice-versa.

The exception object also carries an message, not only a type.
Message carrying can be implemented with error-code return. It's not really exception's privilege.

How big is the speed penalty for using exceptions? I know there is a special frame in every function that deals with exceptions, but I thought it is not very expensive time-wise.
I don't think that the time-penalty is great, but memory is. Example: if you're handling out-of-memory exception as generic exception. You'd catch and re-rise the exeption with your own specific class (i.e. EMyClassCritical). Re-rising would fail with its own exception (within exception handling code) with yet another out-of-memory. Btw, out-of-memory or could be thrown because of a corrupted memory, so handling such exceptions (most commonly seen as "access violation") cause throw more exceptions in the handling code.
I can agree that error code return would not really help, if memory is corrupted, but  the problem might be easier to find since there's less build-up upon it.

I find exceptions as exceptional - and not rising them within my code. (I do however add try...except whenever I'm using others components ... and return false/code, if an exception is caught) :)
« Last Edit: January 24, 2015, 11:14:29 pm by skalogryz »
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

Leledumbo

  • Hero Member
  • *****
  • Posts: 8307
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Static code analysis
« Reply #17 on: January 25, 2015, 05:22:58 am »
The difference from the error code processing, is that exception handling would be out-side of the algorithm in the catch block, with no way to return back.
That's another concept that exception tries to implement. It's the way to separate error handling with the normal algorithm flow, so the normal flow is not cluttered with error checking and handling. Java tutorial serves a good example. What's the example case of returning back after error handling? That sounds like old VB's "On Error Resume Next" which is awwwwwwwwwwwwwwwwwwwwwful...

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2562
    • havefunsoft.com
Re: Static code analysis
« Reply #18 on: January 25, 2015, 05:43:42 am »
What's the example case of returning back after error handling? That sounds like old VB's "On Error Resume Next" which is awwwwwwwwwwwwwwwwwwwwwful...
Good example, btw!
I am attempting to save a file and it fails, since the file is read-only (i.e. on Windows it has "read only" flag).
I may just fail stating to the user "the file is read-only", or instead I might reset the flag, save the file and set the file back.
And this whole operation might also have some sort of user-feedback prompt.

Should I make exception handling part of the algorithm in this case? If yes, what's the difference to processing an error code?
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

Leledumbo

  • Hero Member
  • *****
  • Posts: 8307
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Static code analysis
« Reply #19 on: January 25, 2015, 08:26:20 am »
Good example, btw!
I am attempting to save a file and it fails, since the file is read-only (i.e. on Windows it has "read only" flag).
I may just fail stating to the user "the file is read-only", or instead I might reset the flag, save the file and set the file back.
And this whole operation might also have some sort of user-feedback prompt.

Should I make exception handling part of the algorithm in this case? If yes, what's the difference to processing an error code?
It's up to you actually. The number of if's that exists in the normal flow is the difference, as in the Java tutorial I linked above.

nomorelogic

  • Full Member
  • ***
  • Posts: 136
Re: Static code analysis
« Reply #20 on: January 25, 2015, 02:49:01 pm »
Should I make exception handling part of the algorithm in this case? If yes, what's the difference to processing an error code?

I believe that the exception handling should be used when you need to isolate the code that is required when the algorithm fails. If you need to ask something to the user: it is part of the algorithm.

Again, I like to use the block try..finally to make sure that resources are freed even if an error occurs.

Again I use the block try..except in OnCalcFields event (of a client dataset) to be sure that a miscalculation does not put the application in an undefined state (e.g.: a lookup when client dataset is nil).


skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2562
    • havefunsoft.com
Re: Static code analysis
« Reply #21 on: January 25, 2015, 04:35:41 pm »
It's up to you actually. The number of if's that exists in the normal flow is the difference, as in the Java tutorial I linked above.
It's not up to me anymore, it's up to authors of the library I'm using. If a library rises an exceptions - I've to put exception handling into the main logic to handle them in the same manner as I would error codes. But that defeats the purpose of exceptions. From Java link above: Exceptions provide the means to separate the details of what to do when something out of the ordinary happens from the main logic of a program

Example: To the problem of readonly file I explained before. At the time I'm saing the file I want to catch EUnableToSaveReadOnly file. If the exception is caught I need to update the flag and try saving of the file again. But I don't want to handle EAcccssViolation, if I catch this one, I've to re-rise it. As a result I'm getting two logical kind of exceptions- the error exceptions (the exceptions I expect to receive in this part of the algorithm) and exceptional exceptions (the exceptions I don't expect).
But now these exception handling rules are within the main logic. So what's the benefit?

Now with error codes, my main algorithm would use the codes only to handle "expected" errors. And in many cases it's less typing.
If any exception occurs such as EAccessViolation - I'm not catching them all, so it would up anyway. But this would be an "Exceptional" exception.

Exceptions is a powerful mechanism. Exceptions are exceptional and should be used as such. Otherwise we'd have a horrible set of APIs such as  StrToInt, where every function call must be try...catched.
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

Leledumbo

  • Hero Member
  • *****
  • Posts: 8307
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Static code analysis
« Reply #22 on: January 25, 2015, 05:51:13 pm »
It's not up to me anymore, it's up to authors of the library I'm using. If a library rises an exceptions - I've to put exception handling into the main logic to handle them in the same manner as I would error codes. But that defeats the purpose of exceptions. From Java link above: Exceptions provide the means to separate the details of what to do when something out of the ordinary happens from the main logic of a program
In case of using someone-else-written-library, follow what the author designs the library behavior as.
Example: To the problem of readonly file I explained before. At the time I'm saing the file I want to catch EUnableToSaveReadOnly file. If the exception is caught I need to update the flag and try saving of the file again. But I don't want to handle EAcccssViolation, if I catch this one, I've to re-rise it. As a result I'm getting two logical kind of exceptions- the error exceptions (the exceptions I expect to receive in this part of the algorithm) and exceptional exceptions (the exceptions I don't expect).
But now these exception handling rules are within the main logic. So what's the benefit?
No, main logic does not fail nor it throws exceptions. Your exception handling code is still out of the main logic, you update the flag in the exception handler, not in the main logic.
Exceptions is a powerful mechanism. Exceptions are exceptional and should be used as such. Otherwise we'd have a horrible set of APIs such as  StrToInt, where every function call must be try...catched.
Yes, for sure I don't always use exceptions, especially for small, single file programs. For big ones, I even sometimes create my own exception class with additional properties. When using (swimlane) diagrams, I put exception handling in different lanes from the main logic. The idea is consistent with exception handling benefit, so I can explain the normal flow without being cluttered with error checking and handling logic. The diagram itself should be suitable for both implementations, though.

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2562
    • havefunsoft.com
Re: Static code analysis
« Reply #23 on: January 25, 2015, 05:56:35 pm »
No, main logic does not fail nor it throws exceptions. Your exception handling code is still out of the main logic, you update the flag in the exception handler, not in the main logic.
It has to be in the main logic. Since handling an error from a file function is within the main logic. The main logic is based in that. "If save file failed with "ReadOnly" flag, change the flag and repeat with the save then proceed as normal".
The only issue here, is that since the error is reported via Exception, rather than the error code, I have to put this error handler into the main logic.
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6902
  • Debugger - SynEdit - and more
    • wiki
Re: Static code analysis
« Reply #24 on: January 25, 2015, 06:45:43 pm »
It has to be in the main logic.

Assuming the main logic, is whatever called the procedure in which the failing condition occurred:

Where is the different from returning an error code? An error code also goes back to the caller.
If you check errors immediately, it is mainly a syntactical difference (from the code writing point of view):
Code: [Select]
  e = Foo();
  if e <> 0 then
    case e of
      1: ...;
      2: ...:
      else ...;
    end;
Code: [Select]
  try  // e:=
    Foo();
  except // if e <> 0 then
    on e: TExceptionForError1: ...;
    on e: TExceptionForError2: ...;
    else ...;
  end;

So if desired, both can be used in the same way. Of course, in that case error codes have probably less overhead.

Exceptions add the ability to pass them on to the next caller, by not catching them. Errorcodes must be passed explicitly.
Either has pro and contra, so here is room for personal choices.
- Error code
  - Passing on explicitly makes a statement about the intended behaviour
  - You can ignore a specific error, by not testing for it
  - (But) If you forget to handle it, nothing will ever tell you. (following code may or may not misbehave)
- Exception
  - Passing on by default, may make it easier to find forgotten error handling by catching all on the most outer calling level.
  - If you want to ignore an error, you must explicitly state this, by catching it, and doing nothing in the except handler for that class.


In either case both *allow* to handle the error in the same place: right after the return of the failing function *or* further up the call stack.


« Last Edit: January 25, 2015, 06:50:52 pm by Martin_fr »

z505

  • New Member
  • *
  • Posts: 38
  • think first, code after
Re: Static code analysis
« Reply #25 on: August 20, 2015, 08:28:26 pm »
I know this is an older post from earlier this year, but the Exception vs Error code debate is a hot one and is always relevant, and may never even be solved.. So I am replying... yes I realize it is an old post.

In case of using someone-else-written-library, follow what the author designs the library
behavior as.

And this is the exact problem with exceptions, it assumes the author designs the library correctly and it assumes the author of the library is literally a psychic who can figure out how his library is going to be used in the future.. Library authors are not psychic and cannot anticipate how people are going to use the library. Often the library is designed wrong because 99 percent of people aren't even smart enough to understand exceptions or how those exceptions will always be correctly sprung up in a program..

For those who haven't researched this subject enough I suggest looking up Joel Spolsky's comments on the subject using google... And also Taylor Hutt.

http://www.joelonsoftware.com/items/2003/10/13.html

Exception programming is near impossible to get right... it takes a genius to get it right, and library developers that are even geniuses never get it right. Joel Spolksy has some further info on why this is so. Most people read Spolsky's article and completely miss his point and then go on to continue using exceptions without even getting his point... it's all over the internet, the flamewars are rampant on the subject... Googling this info is helpful if you can put on your thinking cap a bit and understand the subject. It's not an easy subject to understand.

 Exceptions are not the holy grail that solve problems magically.. they often create more problems then they try to resolve. You literally have to be a psychic as a library author to know how to write your exceptions, you have to anticipate how people are going to use your library.. and since libraries are bottom up (people use them for all sorts of things) it is impossible to design a library correctly using exceptions because you cannot anticipate what and how people are going to use your library.  Error codes allow the library to be used how the person wants, whereas exceptions force a specific way (and it is often a wrong way) of error handling on to the user. It's bottom up design vs top down "I know Everything about my end users" attitude.

Plus if your library is cross language (like a DLL) throwing exceptions in pascal can never be dealt with in another language since exception systems are incompatible across languages, whereas errors are completely library compatible with each other...  That's why C programmers rule the world, because they provide us with their libraries for us to wrap and use, whereas pascal just keeps everything to itself and doesn't know much about DLL's or api's.. It's all OOP and exceptions with pascal nowadays and objects/exceptions in pascal are not compatible with C or other languages, so no one reuses pascal code from other language. Continuing pascal's slow but sure death.


Example: To the problem of readonly file I explained before. At the time I'm saing the file I want to catch EUnableToSaveReadOnly file. If the exception is caught I need to update the flag and try saving of the file again. But I don't want to handle EAcccssViolation, if I catch this one, I've to re-rise it. As a result I'm getting two logical kind of exceptions- the error exceptions (the exceptions I expect to receive in this part of the algorithm) and exceptional exceptions (the exceptions I don't expect).
But now these exception handling rules are within the main logic. So what's the benefit?

Not only that, but when you have file opening issues you should NEVER let the end user see an annoying obnoxious exception message.. it's should be a clean message that says "file xyz.txt not opened in abc directory"... not some bizarre cryptic exception scary message that frightens the user such as EFileNnotFoundError &*&*&*#$ STACK TRACE at address *&&*$#

See my comment on that here:
http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Improve-or-Ditch-The-Rude-Exceptions

Exception error messages are not something end users enjoy seeing at all, and end useres will quickly avoid using your software posting bad reviews of it after they get their first obnoxious fearful exception message blurted out to them... It's the typical java exception error junk that makes me dislike Java apps quite a bit.. (there are other issues with Java that I dislike just as much, but that is beyond the scope of this post). Java programmers are confused about what an error is and what an exception is, because no one has scientifically stated what the difference between exceptions and errors are...

Some quotes to remember (also in my wiki) and study (and you really have to think about this carefully to understand it)

    "Exceptions are only generated in the expectation that they will eventually be handled. For this to be possible, a routine which can generate an exception must declare this fact as part of its specification. Full details of all of the consequences of the exception must be provided if it is to be handled effectively. " --Prof. Andrew P. Black, Doctoral Thesis

    "If you have failed the contract, then an unexpected situation has arisen -- it is fundamentally IMPOSSIBLE to program for unexpected situations. Let me restate that: It is impossible to handle unexpected errors!

    The only errors that you can handle are EXPECTED errors, and in that case they should be written into the contract. " --Taylor Hutt, Usenet Post

« Last Edit: August 20, 2015, 08:42:40 pm by z505 »
think first, code after

z505

  • New Member
  • *
  • Posts: 38
  • think first, code after
Re: Static code analysis
« Reply #26 on: August 20, 2015, 09:12:05 pm »
More discussion about possible solutions to the exception versus error code debate is here:
http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Suggestion-for-Modern-Pascal-Error-Contracts

Error contracts would allow the function to make a contract of what error it is going
to throw, instead of the exception being hidden away in some documentation page that
programmers may not even fully read (and the documentation can be wrong)

This is different than just returning an extra var parameter because the error contract can be checked by the compiler, whereas var params as errors are just "roll your own" error systems that the compiler doesn't check.


Go Language by Google has implemented something very similar to error contracts by returning a separate error for functions (functions can return multiple results, a function result for programming logic, and also an error).

Quote from Go Language FAQ
" Why does Go not have exceptions?

We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.

Go takes a different approach. For plain error handling, Go's multi-value returns make it easy to report an error without overloading the return value.
"

But the question is, are these error contracts, like I proposed in my wiki where the compiler can check if you caught the errors? Or did google just create an extra Var param more elegantly without an actual error contract system that can be checked...  Roll your own error systems are something we want to avoid - we want a standard error contract system that compilers can know about at compile time to enforce mission critical errors be checked. Did google solve this problem? I have to do more research on Go Language to find out..

Exceptions are just the new version of GOTO, but even worse, sometimes GOTO can be more
descriptive of the error and better than an exception.
I duscuss that here:
http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Try-Finally-Is-a-GOTO-That-Is-Too-Limited

Linus Torvalds has also discovered this and has written about it in a famous flamewar discussing whether GOTO's are evil.

http://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/

If one claims GOTO's are evil (which pascal programmers generally admit to) then you also have to admit that exceptions are evil (or you just don't understand exceptions.) Exceptions are a topic full of ignorance I'm afraid because people don't even understand how similar an exception is to a goto. Exceptions are the new goto.... the emperor in new clothes.

It is interesting that I wrote the error contract article many many years ago probably before Go Language was invented... so I wonder if some Google person stumbled upon my wiki and thought returning errors as a separate parameter as a contract of the function was a good idea. Probably they came up with the idea themselves and didn't read my wiki, but it is interesting sometimes how people get their ideas.

It's a bit like quantum mechanics quote from Feynman "If you think you understand quantum mechanics, you don't understand quantum mechanics". Errors and exceptions are not an easy subject to understand. If you think you understand exceptions, I'm sorry but you don't understand exceptions.

As for static source code analysis.. this is also an interesting subject. The main problem is getting too many false positives, so the static source code analysis tool has to be more intelligent over time to only find important errors in source code, which is not an easy task.
« Last Edit: August 20, 2015, 09:31:26 pm by z505 »
think first, code after

 

TinyPortal © 2005-2018