Need better command line parameter handling

[cal101]

Dear @rpau,

the --verbose parameter has 2 consequences currently which I need separately in different combinations:

1. More verbose output especially on errors
2. continue-on-error mode

I suggest moving the second function to a new parameter. If you don't want to change current behavior I suggest --stop-on-error. The levels of ouput would be:

Verbose - print stack traces of various exceptions Normal - just print mostly one liners of exceptions above Silent/quiet - Do not print in case of errors

I can provide a pull request when we agree on the semantics.

Cal

[rpau]

Hi Cal,

I do not like to change the current behavior. So, please add "--stop-on-error"

I agree on the verbose levels, but by default, it should be silent.

Thanks a lot 👍

[cal101]

I do not agree on the silent as default but you are the boss. I wasted 2 hours because of silent being the default and code doing nothing on exceptions that pinpointed errors like class not found ex in the semantic checks and security exceptions on class loader. If silent is the default i woud like to be able to activate what i called "normal" level. I would call it "-i" resp. "--info" which would enable one liner warnings to start with. So at least one can decide.

[rpau]

Ok, I get your point. I am concerned if this kind of info affects the "basic" users' opinion about the tool.

I prefer to have something like in maven, which is "-X" that prints everything on console, which is used when you detect a bad on undesired behavior. So, yes, I like the "--info" option.

[cal101]

Understood. Let's keep things under the hood per default. Do you remember my speed improvements? I thought I was able to load semantic information for 20k files in 3 minutes. No, only 7k were loaded, the rest did error silently :-( I fixed that in the mean time but before doing pull requests I wanted to get a consensus on levels. Do you have any objections when I replace some e.printStackTrace with calls to the logging framework?

[rpau]

No, no objections

Cal, then the last changes on the javalang-compiler does not work? because I have just deployed it this morning :S

[cal101]

They work. They make it faster and I don't know any problems with them. I just noticed yesterday that because of a swallowed exception in the walkmod sematic code the version before and after my speedup did not call the visitor for 19k files but only for 7k files. Totally unrelated to the speedup changes. Do you have any bigger source code base where you can reproduce the speedup?

[rpau]

I usually test walkmod with guava and jenkins. Let me check the performance with them