In org.eclipse.cdt.codan.internal.core.CodanRunner I found the following code:
CheckersRegistry chegistry = CheckersRegistry.getInstance();
chegistry contains a lot of Checkers, including a ReturnChecker.
...
for (IChecker checker : chegistry) {
...
((IRunnableInEditorChecker) checker).processModel(model, context);
...
}
This code eventually calls the ReturnChecker's method to search in the statements in a function body (IASTFunctionDefinition) for a return statement. If that statement is missing, reportNoRet() is called. The editor marks the function with "No return, in function returning non-void".
Is there a way to override this ReturnChecker (or any other of the checkers) so that it only in some cases "reportNoRet" is not called? I also like to know if there is a way to add checkers (I couldn't find an extension point).
You could try to extend the class to perform your own checks, but the basic checker will be always used. Maybe it would be better to create a new set of checkers for your language extension. Take a look here, you find how to add new checkers.
You can definitely add new checkers. The extension point, as mentioned in #greywolf82's link, is org.eclipse.cdt.codan.core.checkers.
I'm not aware of a way to modify ReturnChecker's behaviour in a more granular way that disabling specific problem types entirely. You're probably better off disabling ReturnChecker, and copying its code into your own checker with the desired modifications. (The disablement can also be done declaratively using the org.eclipse.cdt.codan.core.checkerEnablement extension point.)
I don't want to disable the warning altogether and I already know why you supposedly shouldn't use Optional as a parameter. However, I don't think it's relevant to my case.
For illustrative purposes, I have code that looks like this:
//IntelliJ reports: 'Optional<ForeignDataTransferObject>' used as type for parameter 'data'
private LocalSystemPerson extractPerson(Optional<ForeignDataTransferObject> data) {
return data
.map(data -> data.getPeopleListWrapper())
.map(peopleListWrapper -> peopleListWrapper.getList())
.map(listOfForeignPeople -> listOfForeignPeople.stream())
.orElseGet(Stream::empty)
.findFirst()
.map(foreignPerson -> convertToLocalSystemPerson(foreignPerson))
.orElse(someFallbackValue);
}
It's getting the list of people then the the first item then converting it. Since I'm calling an external API and getting a data transfer object with a bunch of fields any of which can be null, any collections are wrapped in an extra class, and even then getting an empty list is a valid case. So, I end up with a verbose code like that to convert a single value. I squirrelled it into a separate helper method to avoid having all that verbosity in one place.
However IntelliJ is complaining that I'm passing an Optional parameter. That is something I'd normally agree with but I don't see it as a problem if it's a private method that I am using to save another method from getting too long - I might need to grab more than one value off the data transfer object.
I still want to avoid creating public methods that accept Optional or fields that hold Optional but I want to disable the inspection for private methods.
I'd prefer to not have to annotate each method with #SuppressWarnings("OptionalUsedAsFieldOrParameterType") as it quickly gets annoying. I can have multiple of these methods in various classes that accept some foreign DTO.
Similarly, I also don't want to pass in a non-Optional parameter only to wrap it inside the method. Especially since In some cases I only have an Optional already, so I'd have to unwrap it then wrap it back with something like myMethod(data.orElse(null)) and then do Optiona.ofNullable(parameter) in the method.
All in all, it seems like an unreasonable limitation to always treat that as a problem even if it's not going to be transferring data across systems or across layers, etc.
So, can I disable that generally from the settings for just private methods but nothing else?
For the current moment there is no option to disable the inspection for private methods. Please follow/comment the issue created for your feature request at YouTrack:
https://youtrack.jetbrains.com/issue/IDEA-207468
Thank you
If I want to specify preconditions on the input arguments, what is the idiomatic way when developing KNIME nodes?
Using assert(condition, message) might be efficient and simple, thought its check depends on the VM argument -ea.
Manually checking with if (condition) throw new IllegalArgumentException(message); seems better, but it does not provide extra semantic information when only checking for nulls for example.
There is also the org.knime.core.node.InvalidSettingsException exception. Should that be used for this purpose?
Is there a collection of methods that should be used in KNIME?
Yes, there is a recommended way to signal incorrect inputs, there are specialized methods in org.knime.core.node.util.CheckUtils (from the bundle org.knime.core.util). It has methods for:
non-null checks: checkNotNull, checkArgumentNotNull, checkSettingNotNull
arguments: checkArgument
state: checkState
setting (from UI or flow variable): checkSetting
files: checkDestinationFile, checkSourceFile, checkDestinationDirectory
These allow using templates in the messages which only expanded when the check fails.
You can find example usages with this query.
I am trying to find out a method on how to change the value of a parameter that I have defined and also how to create a new parameter dynamically using REFORMAT component in Clover ETL.
I have written small logic in my transform method which reformat component provides:
function integer transform() {
string myparam1 = getParamValue("MY_PARAM1");
string changeParam = getParamValue("CHANGE_PARAM_VALUE");
if(changeParam =="true"){
myparam1 = myparam1 +"_changed";
}
// update the value of parameter MY_PARAM1
// updateParameter("MY_PARAM1", myparam1 );
// create a new parameter
// createNewParameter("MY_NEW_PARAM", "some_sample_data");
return OK;
}
From clover designer I tried to check for available methods but I have not found any relevant method that helps me to provide the feature that I am looking for.
I am new to Clover ETL so I am facing difficulty in how to accomplish this, please help me if we can achive this using REFORMAT component or do we need to use a different component?
You cannot change value(in easy way, there is maybe a way through direct access with java and model of graph, but this is probably not what you need) of parameters in CloveETL as they are used in static way, all occurences of parameters are resolved during compilation of graph and replaced with resulted values.
If you need dynamic variables, take a look at dictionaries http://doc.cloveretl.com/documentation/UserGuide/topic/com.cloveretl.gui.docs/docs/using-dictionary.html?resultof=%22%64%69%63%74%69%6f%6e%61%72%79%22%20
But you need to think, that dictionary aren't dead replacement for parameters. Static usage of parameters has some points, places of usage, that you cannot replace with dictionary.
BTW why you need to change parameter value during run of the graph? Please explain use case and maybe I could give you some pointers...
You cannot change value of graph parameters as they are set during the initialization phase of the graph.
However, there are a couple of ways of achieving what you probably want:
Opt 1: Run your graph on a schedule and then passing the parameter value from the scheduler.
Opt 2: Whatever component(s) need the modified value of the parameters put them in a subgraph and create a sub-graph parameter with the same name and pass the modified value as part of your input mapping from the main graph to the sub-graph.
I need to change the signature of a method used all over the codebase.
Specifically, the method void log(String) will take two additional arguments (Class c, String methodName), which need to be provided by the caller, depending on the method where it is called. I can't simply pass null or similar.
To give an idea of the scope, Eclipse found 7000 references to that method, so if I change it the whole project will go down. It will take weeks for me to fix it manually.
As far as I can tell Eclipse's refactoring plugin of Eclipse is not up to the task, but I really want to automate it.
So, how can I get the job done?
Great, I can copy a previous answer of mine and I just need to edit a tiny little bit:
I think what you need to do is use a source code parser like javaparser to do this.
For every java source file, parse it to a CompilationUnit, create a Visitor, probably using ModifierVisitor as base class, and override (at least) visit(MethodCallExpr, arg). Then write the changed CompilationUnit to a new File and do a diff afterwards.
I would advise against changing the original source file, but creating a shadow file tree may me a good idea (e.g. old file: src/main/java/com/mycompany/MyClass.java, new file src/main/refactored/com/mycompany/MyClass.java, that way you can diff the entire directories).
Eclipse is able to do that using Refactor -> Change Method signature and provide default values for the new parameters.
For the class parameter the defaultValue should be this.getClass() but you are right in your comment I don't know how to do for the method name parameter.
IntelliJ IDEA shouldn't have any trouble with this.
I'm not a Java expert, but something like this could work. It's not a perfect solution (it may even be a very bad solution), but it could get you started:
Change the method signature with IntelliJ's refactoring tools, and specify default values for the 2 new parameters:
c: self.getClass()
methodName: Thread.currentThread().getStackTrace()[1].getMethodName()
or better yet, simply specify null as the default values.
I think that there are several steps to dealing with this, as it is not just a technical issue but a 'situation':
Decline to do it in short order due to the risk.
Point out the issues caused by not using standard frameworks but reinventing the wheel (as Paul says).
Insist on using Log4j or equivalent if making the change.
Use Eclipse refactoring in sensible chunks to make the changes and deal with the varying defaults.
I have used Eclipse refactoring on quite large changes for fixing old smelly code - nowadays it is fairly robust.
Maybe I'm being naive, but why can't you just overload the method name?
void thing(paramA) {
thing(paramA, THE_DEFAULT_B, THE_DEFAULT_C)
}
void thing(paramA, paramB, paramC) {
// new method
}
Do you really need to change the calling code and the method signature? What I'm getting at is it looks like the added parameters are meant to give you the calling class and method to add to your log data. If the only requirement is just adding the calling class/method to the log data then Thread.currentThread().getStackTrace() should work. Once you have the StackTraceElement[] you can get the class name and method name for the caller.
If the lines you need replaced fall into a small number of categories, then what you need is Perl:
find -name '*.java' | xargs perl -pi -e 's/log\(([^,)]*?)\)/log(\1, "foo", "bar")/g'
I'm guessing that it wouldn't be too hard to hack together a script which would put the classname (derived from the filename) in as the second argument. Getting the method name in as the third argument is left as an exercise to the reader.
Try refactor using intellij. It has a feature called SSR (Structural Search and Replace). You can refer classes, method names, etc for a context. (seanizer's answer is more promising, I upvoted it)
I agree with Seanizer's answer that you want a tool that can parse Java. That's necessary but not sufficient; what you really want is a tool that can carry out a reliable mass-change.
To do this, you want a tool that can parse Java, can pattern match against the parsed code, install the replacement call, and spit out the answer without destroying the rest of the source code.
Our DMS Software Reengineering Toolkit can do all of this for a variety of languages, including Java. It parses complete java systems of source, builds abstract syntax trees (for the entire set of code).
DMS can apply pattern-directed, source-to-source transformations to achieve the desired change.
To achieve the OP's effect, he would apply the following program transformation:
rule replace_legacy_log(s:STRING): expression -> expression
" log(\s) " -> " log( \s, \class\(\), \method\(\) ) "
What this rule says is, find a call to log which has a single string argument, and replace it with a call to log with two more arguments determined by auxiliary functions class and method.
These functions determine the containing method name and containing class name for the AST node root where the rule finds a match.
The rule is written in "source form", but actually matches against the AST and replaces found ASTs with the modified AST.
To get back the modified source, you ask DMS to simply prettyprint (to make a nice layout) or fidelity print (if you want the layout of the old code preserved). DMS preserves comments, number radixes, etc.\
If the exisitng application has more than one defintion of the "log" function, you'll need to add a qualifier:
... if IsDesiredLog().
where IsDesiredLog uses DMS's symbol table and inheritance information to determine if the specific log refers to the definition of interest.
Il fact your problem is not to use a click'n'play engine that will allow you to replace all occurences of
log("some weird message");
by
log(this.getClass(), new Exception().getStackTrace()[1].getMethodName());
As it has few chances to work on various cases (like static methods, as an example).
I would tend to suggest you to take a look at spoon. This tool allows source code parsing and transformation, allowing you to achieve your operation in a -obviously code based- slow, but controlled operation.
However, you could alos consider transforming your actual method with one exploring stack trace to get information or, even better, internally use log4j and a log formatter that displays the correct information.
I would search and replace log( with log(#class, #methodname,
Then write a little script in any language (even java) to find the class name and the method names and to replace the #class and #method tokens...
Good luck
If the class and method name are required for "where did this log come from?" type data, then another option is to print out a stack trace in your log method. E.g.
public void log(String text)
{
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter(sw, true);
new Throwable.printStackTrace(pw);
pw.flush();
sw.flush();
String stackTraceAsLog = sw.toString();
//do something with text and stackTraceAsLog
}