Menu

#9 Warnings mechanism

closed-fixed
nobody
5
2018-08-01
2005-11-25
Ian Roberts
No

Currently a processing resource can either complete suuccessfully or it
can fail with an exception. However, there are many cases where a PR
encounters a problem that it should warn the user about but which is
not a fatal error. The only way to handle these cases at present is to
write a message to System.out, which will then appear in the Messages
window (or standard output when running without the GUI), but there
is no general way for the user to surpress these messages.

For individual PRs the author can choose to provide a runtime
parameter, say, surpressWarnings, and wrap their warning messages in
a test of this parameter, but it would be useful for GATE to provide a
unified way for PRs to produce warnings. I envisage something like:

class MyPR {

init() throws ResourceInstantiationException {
if(someNonFatalCondition) {
PRUtils.initWarn("fancy-thing not available, results may be biased");
}
}

execute() throws ExecutionException {
...
if(pingBroken) {
PRUtils.executeWarn("PING broken");
}
}
}

There could then be an option in the GUI (or gate.xml) to either ignore
warnings altogether, print them but carry on, or make the warn
methods throw the relevant GATE exception, and so make the warning
conditions fatal. Finer grained logging may be desirable, in which case
the user could set log level thresholds, say "ignore everything below
level 3, warn from level 4 to 8, fail above level 9".

Discussion

  • Hamish Cunningham

    Logged In: YES
    user_id=1136362

    I may have misunderstood, but at the API level comments can
    be redirected via Out.setPrintWriter or somesuch. I agree
    that a problem signalling method might be useful.

     
  • Hamish Cunningham

    Logged In: YES
    user_id=1136362

    PS probably log4j or the java one (which is simpler, I
    think) is the long-term solution to messages

     
  • Mark Greenwood

    Mark Greenwood - 2018-08-01

    Many of the PRs now have proper logging in them. It's not common across all PRs or in their interface etc. but I think it means this issue is essentially covered, so to clean up the list here (new issues are on github) I'm going to close this and mark it as done

     
  • Mark Greenwood

    Mark Greenwood - 2018-08-01
    • status: open --> closed-fixed
    • Group: --> Next_Release_(example)
     

Log in to post a comment.