How prevent PlantUML from creating error images?

0 votes
asked Jun 16 in Question / help by DDDsa (200 points)

When PlantUML console tool encounters syntax error in a diagram it generates an image with error traceback like the following:

Is there a way to disable generating error images and possibly output the traceback into stderr instead?


I generate images from several source files with PlantUML CLI like this:

$ plantuml diag1.puml diag2.puml diag3.puml

Some of these diagrams may have faulty syntax, I need the faulty ones to be skipped.

I could parse the stderr and get faulty diagram names from there, but that's the last resort. I believe there should be a native option for mentioned behavior.

commented Jun 16 by The-Lu (31,160 points)

Hello D.,

Perhaps you can test:

    -syntax     To report any syntax error from standard input without generating images
    -checkonly  To check the syntax of files without generating images
    -failfast   To stop processing as soon as a syntax error in diagram occurs
    -failfast2  To do a first syntax check before processing files, to fail even faster

See all option, with:

    java -jar plantuml.jar -h   

If that can help,

commented Jun 16 by DDDsa (200 points)

@The-Lu thank you for your answer!
I've studied available options, but unfortunately none of them helps.

I'll explain my situation in details: we use plantuml in a Python tool to generate diagrams for our documents. In one document there may be many diagrams, and some of them may be faulty because technical writers are people too and make mistakes. Now we generate each diagram one by one and there is no problem — we run plantuml diag.puml and if the command fails, then the diagram is faulty, we can alert the author in the console and move the generated error image to a subdir for author to study.

The problem is that when number of diagrams in a document grows, we get a massive overhead for launching separate plantuml instance for each diagram. There is an obvious solution: run plantuml once for all diagrams: plantuml diag1.puml diag2.puml diag3.puml.  It works great if all diagrams are correct, but if some of them are faulty we need to determine which of the generated images are error reports and move them to the subdir (this is essential in our case, we have to move or rename them). Determining that is awkward: I need to parse plantuml's stderr output, get the names of faulty diagrams and then change their extensions to the output format (which may vary in our case). It would be much easier if plantuml just didn't generate error images at all.

-syntax and -checkonly won't work because I will have to run them for each diagram separately which will bring back the overhead of launching multiple plantumls. As far as I understood, -checkonly doesn't give you the names of faulty diagrams when applied to several files?

-failfast stops rendering diagrams when first faulty one is encountered (and error image for it is still rendered), but I need other diagrams still to be processed.

-failfast2 just doesn't render anything if any of the diagrams is faulty.

commented Jun 17 by The-Lu (31,160 points)

1 Answer

0 votes
answered Jun 17 by DDDsa (200 points)

It seems that the only way to achieve this is to run PlantUML in -pipe mode with -pipeNoStderr parameter.

It enforced me to completely rewrite our tool which generates diagrams, but the main thing is that it works.

I hope a similar parameter will appear for a normal mode in the future.

commented Jun 22 by plantuml (257,860 points)
We could add a new parameter, but we need your help here.

Let's say we add a new flag -dddsa :-)

Could you document exactly what is the expected behavior of this flag ?

Thanks !
commented Jun 22 by DDDsa (200 points)


Haha flag -dddsa would be funny : } I thought of something like

-noErrorImages    To output errors in stderr instead of generating images with errors.

Long description:

If diagram contains syntax errors and flag -noErrorImages is present, PlantUML will output error info in stderr instead of generating an image with error info. No output file is created in this case.

The message in stderr should include the name of source diagram, which contained errors. This way you could determine which error traceback coresponds to which diagram if several source files were supplied, for example:

$ plantuml -noErrorImages diag1.puml diag2.puml diag3.puml

ERROR in diag1.puml
Syntax Error?
ERROR in diag3.puml
Syntax Error?

In this example only file diag2.puml was generated as the result of the command.

commented Jun 22 by The-Lu (31,160 points)

Hello all,

And if combine with '-stdrpt' the output will be (conform to gcc or grep output) as:

$ plantuml -noErrorImages -stdrpt diag1.puml diag2.puml diag3.puml

diag1.puml:1:error:Syntax Error?
diag3.puml:17:error:Syntax Error?


commented Jun 24 by plantuml (257,860 points)

Thanks all for your ideas and suggestions. So with last beta you can have:

java -jar plantuml.jar -noerror -stdrpt *.puml

Tell us if it works for you !

commented Jun 27 by DDDsa (200 points)


Sorry for late reply, I'm currently on vacation and internet is not always good.

This one doesn't work as expected:

I have three diagram files: diag1.puml, diag2.puml and diag3.puml. Diagrams 1 and 3 contain errors, diagram 2 is good. If I run

java -jar plantuml.jar -noerror diag1.puml diag2.puml diag3.puml

I get:

Error line 2 in file: diag1.puml
Error line 2 in file: diag3.puml
Some diagram description contains errors

Which is great, but good diagram diag2.puml is not rendered. Expected result: only diag2.png is rendered, diag1 and diag3 are skipped.

If I run the command only with good diagram:

java -jar plantuml.jar -noerror diag2.puml

Nothing is written in output (which is good), but the image diag2.png is not rendered either, so in this case running the command doesn't do anything. Expected result: diag2.png is rendered.

commented Jun 28 by plantuml (257,860 points)

Sorry for late reply, I'm currently on vacation and internet is not always good.

No problem, enjoy your holidays :-)

Of course, you are right... this should be fixed in last beta

Sorry about that!

commented Jul 5 by DDDsa (200 points)
Perfect! This one works as expected!