New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pop-Up box with FileNotFoundException when including directory #19

Closed
redcatbear opened this Issue Mar 13, 2017 · 9 comments

Comments

Projects
None yet
3 participants
@redcatbear

Situation

When using the !include feature of PlantUML and stopping to type where the included path points to a directory, a pop-up dialog appears that contains a java.io.FileNotFoundException.

This breaks the typing flow since users have to click away the pop-up in order to be able to type again.

When using the include feature this happens regularly since you typically stop a part of the path trying to remember the rest.

Expected behavior

  • A none intrusive error message is displayed (e.g. some kind of status entry)
  • The error message does not block typing

Actual behavior

  • Typing is blocked until pop-up dialog is closed.

Reproducibility

100%

Steps to Reproduce

  1. Create empty diagram
  2. Add `!include" directive
  3. Type path to directory after include directive
  4. Wait for dialog to pop up

Screenshot

plantuml-eclipse-plugin_dircetory_exception

Environment

Eclipse 4.6.0, PlantUML Feature 1.1.8.8058, Linux (Ubuntu)

Also observed in older versions of the plug-in, other versions of Eclipse and on Windows.

@hallvard

This comment has been minimized.

Show comment
Hide comment
@hallvard

hallvard Mar 13, 2017

Owner

I've never seen this, but haven't used include either. I agree a less intrusive message is best, unfortunately there isn't an obvious place to put it, besides in the diagram (like what happens now, if there is a syntax error). My suggestion is to write the stack trace into an image in the diagram, as shown in the screenshot below.

plantuml-exception

Owner

hallvard commented Mar 13, 2017

I've never seen this, but haven't used include either. I agree a less intrusive message is best, unfortunately there isn't an obvious place to put it, besides in the diagram (like what happens now, if there is a syntax error). My suggestion is to write the stack trace into an image in the diagram, as shown in the screenshot below.

plantuml-exception

@arnaudroques

This comment has been minimized.

Show comment
Hide comment
@arnaudroques

arnaudroques Mar 13, 2017

Collaborator

The exception is thrown by PlantUML library itself. So we (ie PlantUML team) could change this behaviour and not throw an exception in that case.
I think it is the best solution.

Collaborator

arnaudroques commented Mar 13, 2017

The exception is thrown by PlantUML library itself. So we (ie PlantUML team) could change this behaviour and not throw an exception in that case.
I think it is the best solution.

@hallvard

This comment has been minimized.

Show comment
Hide comment
@hallvard

hallvard Mar 13, 2017

Owner

There needs to be an indication that the diagram cannot be generated. This happens now, if you type a file name that doesn't exist at all, but in the "usual" way as with syntax errors: You get an image with the error message. I suggest that the library should do the same with this case, to make it uniform.

There may still be errors that we don't know of, that could be reported as shown above. Summarising:

  • all errors concerning diagram syntax etc. should be reported in the same way, so include of a directory should be handled similar to include of files that don't exist
  • other errors (bugs), can be shown as above, to help users report bugs
Owner

hallvard commented Mar 13, 2017

There needs to be an indication that the diagram cannot be generated. This happens now, if you type a file name that doesn't exist at all, but in the "usual" way as with syntax errors: You get an image with the error message. I suggest that the library should do the same with this case, to make it uniform.

There may still be errors that we don't know of, that could be reported as shown above. Summarising:

  • all errors concerning diagram syntax etc. should be reported in the same way, so include of a directory should be handled similar to include of files that don't exist
  • other errors (bugs), can be shown as above, to help users report bugs
@redcatbear

This comment has been minimized.

Show comment
Hide comment
@redcatbear

redcatbear Mar 13, 2017

@hallvard, @arnaudroques: I agree that a consistent way to handle this case would be preferable. Rendering it into the document-internal error message sounds reasonable to me.

@hallvard, @arnaudroques: I agree that a consistent way to handle this case would be preferable. Rendering it into the document-internal error message sounds reasonable to me.

@redcatbear

This comment has been minimized.

Show comment
Hide comment
@redcatbear

redcatbear Mar 13, 2017

Side note: kudos for answering so quickly! This is what I call an actively maintained project.
👍

A lot of the programmers I work with use PlantUML and the plug-in on a daily basis.

Side note: kudos for answering so quickly! This is what I call an actively maintained project.
👍

A lot of the programmers I work with use PlantUML and the plug-in on a daily basis.

@arnaudroques

This comment has been minimized.

Show comment
Hide comment
@arnaudroques

arnaudroques Mar 13, 2017

Collaborator

A new beta is available with better error handling :
https://dl.dropboxusercontent.com/u/13064071/plantuml.jar

Right now, we just catch the exception and generate an error image.
If this image generation is ok to you, we could make some checks in next versions (does the file exist? It is a real file? a directory?) to print a more user friendly message.

Collaborator

arnaudroques commented Mar 13, 2017

A new beta is available with better error handling :
https://dl.dropboxusercontent.com/u/13064071/plantuml.jar

Right now, we just catch the exception and generate an error image.
If this image generation is ok to you, we could make some checks in next versions (does the file exist? It is a real file? a directory?) to print a more user friendly message.

@redcatbear

This comment has been minimized.

Show comment
Hide comment
@redcatbear

redcatbear Mar 13, 2017

@arnaudroques: could you please publish the SHA256 of the dropbox file here on Github?

@arnaudroques: could you please publish the SHA256 of the dropbox file here on Github?

@arnaudroques

This comment has been minimized.

Show comment
Hide comment
@arnaudroques

arnaudroques Mar 13, 2017

Collaborator

Sure
hex: 8a1378134b099cde620541e9c3285b83199275210e76adbd86fd25a32bf44544
base64: ihN4E0sJnN5iBUHpwyhbgxmSdSEOdq29hv0loyv0RUQ=

Collaborator

arnaudroques commented Mar 13, 2017

Sure
hex: 8a1378134b099cde620541e9c3285b83199275210e76adbd86fd25a32bf44544
base64: ihN4E0sJnN5iBUHpwyhbgxmSdSEOdq29hv0loyv0RUQ=

@redcatbear

This comment has been minimized.

Show comment
Hide comment
@redcatbear

redcatbear Mar 13, 2017

The error message is rendered into the diagram:
error_message_rendered_into_diagram

The rendered image also tries to render a class diagram from the error message which looks kind of funny and is probably not intended.

I still get the pop-up when I exchange the plantuml.jar in the plug-in under lib/plantUml though, which looks like the exception still falls through.

The error message is rendered into the diagram:
error_message_rendered_into_diagram

The rendered image also tries to render a class diagram from the error message which looks kind of funny and is probably not intended.

I still get the pop-up when I exchange the plantuml.jar in the plug-in under lib/plantUml though, which looks like the exception still falls through.

@hallvard hallvard closed this Apr 5, 2017

@hallvard hallvard self-assigned this Apr 6, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment