2024-03-29 19:47 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000477mercuryFeature Requestpublic2019-04-20 14:58
Reporterjuliensf 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000477: Infinite recursion through exception handlers
DescriptionCode such as the following is may be worth a warning.

:- pred reconstruct_route(logger::in, jscenario::in, jsolution::out)
    is cc_multi.

reconstruct_route(Log, JScenario, JSolution) :-
    ( try []
        reconstruct_route(Log, JScenario, JSolution0)
    then
        JSolution = JSolution0
    catch_any Excp ->
        trace [io(!IO)] (
            Msg = "Exception during route reconstruction: " ++ string(Excp),
            slf4j.error(Log, Msg, !IO)
        ),
        JSolution = null_jsolution
    ).
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0001023

zs (developer)

Can you please add a full test case?

~0001029

juliensf (administrator)

There's a cut-down version that exhibits the behaviour attached. The current check carried out by simplify for recursive calls with the same input arguments doesn't look through higher-order calls since in general it cannot. I suspect it may be worth making a special case of try/2 (and its syntax sugared form) since wrapping an exception handler around the entry point to a Mercury program that is called from a foreign language application (which is the original setting for this) is not uncommon. Nor unfortunately is forgetting to use the correct predicate name inside the try goal which is what I did :-(

~0001038

zs (developer)

Feature implemented 2019 April 20.
+Notes

-Issue History
Date Modified Username Field Change
2019-04-17 16:51 juliensf New Issue
2019-04-17 22:28 zs Note Added: 0001023
2019-04-18 00:37 juliensf File Added: bug477.m
2019-04-18 00:37 juliensf Note Added: 0001029
2019-04-20 08:57 zs Assigned To => zs
2019-04-20 08:57 zs Status new => assigned
2019-04-20 14:58 zs Status assigned => resolved
2019-04-20 14:58 zs Resolution open => fixed
2019-04-20 14:58 zs Note Added: 0001038
+Issue History