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'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?
Although surprised that pragma No_Exception_Propagation seems toSome people reserve exceptions for signalling errors. I regard them as a
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 aroundI definitely would prefer an exception, on the ground that you can omit
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 typeAn interesting idea for AdaControl, especially if you have some funding
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.
On 2021-10-15 19:48, J-P. Rosen wrote:back to top level when you have found what you were looking for. Some would disagree with that.
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
I strongly believe that this is the only consistent way to treat exceptions.
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, theyI strongly believe that this is the only consistent way to treat exceptions.
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.
On 15.10.21 20:03, Dmitry A. Kazakov wrote:go back to top level when you have found what you were looking for. Some would disagree with that.
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
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?
On 15.10.21 20:03, Dmitry A. Kazakov wrote:
On 2021-10-15 19:48, J-P. Rosen wrote:
Once found, pass the result to the party that needs it.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.
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?
I have read that exceptions should not be used for code flow.
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?
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.Exceptions is having two results: data read or file end, commit or
Then, finish the computational task that found the result.
Is there anything besides exceptions to do that, and orderly?
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 379 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 44:03:44 |
| Calls: | 8,141 |
| Calls today: | 4 |
| Files: | 13,085 |
| Messages: | 5,857,952 |