Code flow control

Code flow control

[Kevin Chadwick]

Although surprised that pragma No_Exception_Propagation seems to prevent access to some exception information. I am happy with Adas exception mechanism. I have read that exceptions should not be used for code flow.

For Ada after perusing various threads on this mailing list around best practice I am considering using exceptions locally but also have an in out variable for code flow control at the point of use. Is that the way with the caveat that it all depends on the task at hand?

In Go with vscode a static checker will warn if an error type variable is returned without a following if error utilisation (check usually of the form if err /= nil).

I have read that Spark has some kind of static analysis to achieve similar as it forbids exceptions.

It is not the end of the world but is there any static analyser that could do similar for Ada. IOW save me some time or perhaps worse whenever I have simply omitted the check by accident, in haste or distraction.

I'm sure I could quickly write a shell script easily enough for a specific design as in if keyword appears once but not again within x lines then shout at me but I am wondering if I am missing a tool or better practice before I do so?

Re: Code flow control

[J-P. Rosen]

Le 15/10/2021 à 17:08, Kevin Chadwick a écrit :
> Although surprised that pragma No_Exception_Propagation seems to
> prevent access to some exception information. I am happy with Adas
> exception mechanism. I have read that exceptions should not be used
> for code flow.
Some people reserve exceptions for signalling errors. I regard them as a 
way to handle "exceptional" situations, i.e. when the normal flow of 
control cannot continue. For example, in a deep recursive search, they 
are handy to stop the recursion and go back to top level when you have 
found what you were looking for. Some would disagree with that.

> For Ada after perusing various threads on this mailing list around
> best practice I am considering using exceptions locally but also have
> an in out variable for code flow control at the point of use. Is that
> the way with the caveat that it all depends on the task at hand?
I definitely would prefer an exception, on the ground that you can omit 
the check, but you cannot ignore an exception.

> In Go with vscode a static checker will warn if an error type
> variable is returned without a following if error utilisation (check
> usually of the form if err /= nil).
> 
> I have read that Spark has some kind of static analysis to achieve
> similar as it forbids exceptions.
> 
> It is not the end of the world but is there any static analyser that
> could do similar for Ada. IOW save me some time or perhaps worse
> whenever I have simply omitted the check by accident, in haste or
> distraction.
An interesting idea for AdaControl, especially if you have some funding 
for it ;-)

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

Re: Code flow control

[Dmitry A. Kazakov]

On 2021-10-15 19:48, J-P. Rosen wrote:

> Some people reserve exceptions for signalling errors. I regard them as a 
> way to handle "exceptional" situations, i.e. when the normal flow of 
> control cannot continue. For example, in a deep recursive search, they 
> are handy to stop the recursion and go back to top level when you have 
> found what you were looking for. Some would disagree with that.

I strongly believe that this is the only consistent way to treat exceptions.

What I do wish is carefully designed exception contracts in Ada.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Code flow control

[Kevin Chadwick]

On Friday, 15 October 2021 at 19:03:20 UTC+1, Dmitry A. Kazakov wrote:
> On 2021-10-15 19:48, J-P. Rosen wrote: 
> 
> > Some people reserve exceptions for signalling errors. I regard them as a 
> > way to handle "exceptional" situations, i.e. when the normal flow of 
> > control cannot continue. For example, in a deep recursive search, they 
> > are handy to stop the recursion and go back to top level when you have 
> > found what you were looking for. Some would disagree with that.
> I strongly believe that this is the only consistent way to treat exceptions. 

If I am not mistaken.The ada 95 style guide states that you should not end a loop with an exception, on purpose.

Re: Code flow control

[G.B.]

On 15.10.21 20:03, Dmitry A. Kazakov wrote:
> On 2021-10-15 19:48, J-P. Rosen wrote:
> 
>> Some people reserve exceptions for signalling errors. I regard them as a way to handle "exceptional" situations, i.e. when the normal flow of control cannot continue. For example, in a deep recursive search, they are handy to stop the recursion and go back to top level when you have found what you were looking for. Some would disagree with that.
> 
> I strongly believe that this is the only consistent way to treat exceptions.

Once found, pass the result to the party that needs it.
Then, finish the computational task that found the result.
Is there anything besides exceptions to do that, and orderly?

Re: Code flow control

[Kevin Chadwick]

On Friday, 15 October 2021 at 21:02:49 UTC+1, G.B. wrote:
> On 15.10.21 20:03, Dmitry A. Kazakov wrote: 
> > On 2021-10-15 19:48, J-P. Rosen wrote: 
> > 
> >> Some people reserve exceptions for signalling errors. I regard them as a way to handle "exceptional" situations, i.e. when the normal flow of control cannot continue. For example, in a deep recursive search, they are handy to stop the recursion and go back to top level when you have found what you were looking for. Some would disagree with that. 
> > 
> > I strongly believe that this is the only consistent way to treat exceptions.
> Once found, pass the result to the party that needs it. 
> Then, finish the computational task that found the result. 
> Is there anything besides exceptions to do that, and orderly?

I believe the ada 95 style guide recommended a standard goto?

Re: Code flow control

[Randy Brukardt]

"Kevin Chadwick" <kevc3no4@gmail.com> wrote in message 
news:23031592-5a56-4d56-bda7-34877588802dn@googlegroups.com...
On Friday, 15 October 2021 at 21:02:49 UTC+1, G.B. wrote:
> On 15.10.21 20:03, Dmitry A. Kazakov wrote:
> > On 2021-10-15 19:48, J-P. Rosen wrote:

>> >> Some people reserve exceptions for signalling errors. I regard them as 
>> >> a way to handle "exceptional" situations, i.e. when the normal flow of 
>> >> control cannot continue. For example, in a deep recursive search, they 
>> >> are handy to stop the recursion and go back to top level when you have 
>> >> found what you were looking for. Some would disagree with that.
>> >
>> > I strongly believe that this is the only consistent way to treat 
>> > exceptions.
>> Once found, pass the result to the party that needs it.
>> Then, finish the computational task that found the result.
>> Is there anything besides exceptions to do that, and orderly?

>I believe the ada 95 style guide recommended a standard goto?

Gotos only work within a single invocation of a single subprogram. It is 
rarely the case that some complex computation only uses one subprogram, and 
that's never the case in a recursive search (the example that J-P gave).

A program that tries to handle end-of-file by calling End_of_File all over 
is (a) way more complex than necessary, and (b) likely to be wrong as some 
case is missed. Handling End_Error makes way more sense.

Of course, if you *are* in a single subprogram, then the advice of the style 
guide is good (exceptions having more overhead than gotos, especially when 
they actually occur). They're best used when multiple subprograms (or 
subprogram calls) are involved.

                              Randy.

Re: Code flow control

[Dmitry A. Kazakov]

On 2021-10-15 22:02, G.B. wrote:
> On 15.10.21 20:03, Dmitry A. Kazakov wrote:
>> On 2021-10-15 19:48, J-P. Rosen wrote:
>>
>>> Some people reserve exceptions for signalling errors. I regard them 
>>> as a way to handle "exceptional" situations, i.e. when the normal 
>>> flow of control cannot continue. For example, in a deep recursive 
>>> search, they are handy to stop the recursion and go back to top level 
>>> when you have found what you were looking for. Some would disagree 
>>> with that.
>>
>> I strongly believe that this is the only consistent way to treat 
>> exceptions.
> 
> Once found, pass the result to the party that needs it.
> Then, finish the computational task that found the result.
> Is there anything besides exceptions to do that, and orderly?

Exceptions is having two results: data read or file end, commit or 
rollback, item parsed or syntax error, next item or completed etc. 
Consequently there are two paths of execution, one per result. The more 
frequent/regular/complex path runs as the normal flow another does as 
exception propagation.

In a data flow architecture you can have as many paths as you wanted, 
e.g. in a state machine. That does not work well as programming 
paradigm. Two paths is just how much the programmer can handle.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Code flow control

[Kevin Chadwick]

On Saturday, October 16, 2021 at 8:50:04 AM UTC+1, Dmitry A. Kazakov wrote:
> On 2021-10-15 22:02, G.B. wrote: 
> > On 15.10.21 20:03, Dmitry A. Kazakov wrote: 
> >> On 2021-10-15 19:48, J-P. Rosen wrote: 
> >> 
> >>> Some people reserve exceptions for signalling errors. I regard them 
> >>> as a way to handle "exceptional" situations, i.e. when the normal 
> >>> flow of control cannot continue. For example, in a deep recursive 
> >>> search, they are handy to stop the recursion and go back to top level 
> >>> when you have found what you were looking for. Some would disagree 
> >>> with that. 
> >> 
> >> I strongly believe that this is the only consistent way to treat 
> >> exceptions. 
> > 
> > Once found, pass the result to the party that needs it. 
> > Then, finish the computational task that found the result. 
> > Is there anything besides exceptions to do that, and orderly?
> Exceptions is having two results: data read or file end, commit or 
> rollback, item parsed or syntax error, next item or completed etc. 
> Consequently there are two paths of execution, one per result. The more 
> frequent/regular/complex path runs as the normal flow another does as 
> exception propagation. 
> 
> In a data flow architecture you can have as many paths as you wanted, 
> e.g. in a state machine. That does not work well as programming 
> paradigm. Two paths is just how much the programmer can handle.
> -- 
> Regards, 
> Dmitry A. Kazakov 
> http://www.dmitry-kazakov.de

My experience with exceptions and try catch even, is limited.

I am a little confused as to the optimum extent of their use between 
this thread and the thread "best practice: error handling"

"https://groups.google.com/g/comp.lang.ada/c/xL0qGSUQSbE/m/N8LJ8VNMJEQJ"

I will look at some code on github to further my understanding. 
If anyone has any links to good examples, then that would be useful?

Regards,
kc

Re: Code flow control

[Kevin Chadwick]

Whilst I like that exceptions with the GNAT compiler provide warnings 
with pragma No_Exception_Propagation and that they cannot be 
ignored at runtime.

Some of the comments agree but some seem to conflict with this video
 about code flow. I agree with the video, actually. Especially wrt spaghetti 
code potential and even more so, when declare blocks are in use.

"https://youtu.be/cv0l1LnhYmE"

Re: Code flow control

[Jeffrey R. Carter]

On 10/15/21 5:08 PM, Kevin Chadwick wrote:
> 
> I'm sure I could quickly write a shell script easily enough for a specific design as in if keyword appears once but not again within x lines then shout at me but I am wondering if I am missing a tool or better practice before I do so?

What you're talking about is result codes. Exceptions exist because of problems 
people encountered with result codes. Using result codes when you have 
exceptions is like using conditional go-tos when you have if statements.

So, yes, there is better practice. It's called exceptions.

-- 
Jeff Carter
"I'll get broads up here like you wouldn't believe.
Swingers. Freaks. Nymphomaniacs. Dental hygienists."
Play It Again, Sam
125

Re: Code flow control

[Roger Mc]

On Saturday, October 16, 2021 at 2:08:44 AM UTC+11, kevc...@gmail.com wrote:
>  I have read that exceptions should not be used for code flow. 

I strongly agree  that exceptions should not be used for code flow.
However, I do use them in some file handling situations.
I wondered about using assertions, but then thought probably not relevant.
Using them for code flow seems tantamount to using go-tos. 

Roger