#55 Max Length of Exceptions in alert

[Anonymous]

One of my testers found an issue with how errors are displayed within the dialog box when the prompt is a result of an exception. If you look at the exception processing logic in the displayError method of the wjhk.jupload2.policies.DefaultUploadPolicy class. For most paths that are taken to display alerts within the class you will see the formatMessage method executed. However if you look at the function below you will notice that it isn't executed at all. What this results in is one extremely long line of text displayed on the users machine and for my users the dialog box was longer than the width of their monitors.

1046 public int displayErr(String errorText, Exception exception, int optionTypes) {
1047 // Then, we display it to the user.
1048 String alertMsg = errorText;
1049 // Then, the message body can be completed by the exception message.
1050 if (exception != null && (errorText == null || errorText.equals(""))) {
1051 // Ok, we have an exception.
1052 if (exception.getCause() != null) {
1053 alertMsg = exception.getCause().getMessage();
1054 } else {
1055 alertMsg = exception.getMessage();
1056 }
1057 }
1058
1059 // The message displayed depend on the debug level:
1060 if (getDebugLevel() >= 30 && exception != null) {
1061 alertMsg = exception.getClass().getName() + ": " + alertMsg;
1062 }
1063
1064 // Display the message to the user. The kind of alert box depends on the
1065 // given options:
1066 int buttonClicked = 0;
1067 switch (optionTypes) {
1068 case -1:
1069 // Standard message box.
1070 alertStr(alertMsg);
1071 buttonClicked = JOptionPane.OK_OPTION;
1072 break;
1073 case JOptionPane.OK_CANCEL_OPTION:
1074 case JOptionPane.YES_NO_CANCEL_OPTION:
1075 case JOptionPane.YES_NO_OPTION:
1076 buttonClicked = confirmDialogStr(alertMsg, optionTypes);
1077 break;
1078 default:
1079 // This is a problem. Let's display it to the user as a standard
1080 // alert box.
1081 alertStr(alertMsg);
1082 buttonClicked = JOptionPane.OK_OPTION;
1083 // Then, we log this new problem.
1084 String msg = "Unknown optionType in displayErr(String, Exception, int)";
1085 alertStr(msg);
1086 logErr(msg, null);
1087 }
1088
1089 // First, we log the error.
1090 logErr(errorText, exception);
1091
1092 return buttonClicked;
1093 }

If you look at lines 1070 and 1081, then we can add a call to formatMessage to take care of this issue, but I wasn't sure if this method call was left out intentionally.

If this is something that we would like to add to the next version then I can submit a patch.

[Etienne]

Hi,

Actually, I'm not happy with the logging part. At all. I construct little step by little step, which make it now be some hard-to-understand stuff.
With the kind of bug you precised.

I don't want to use log4j (or any others) to make JUpload remain as small as possible. But the whole stuff should be reviewed.
I'll do it, in the future .... perhaps.

BTW, for now, I'll be happy to receive and apply a patch on this one.

Or, better : I had you as a developper on JUpload.
Please commit directly on SVN.

Which IDE are you using ?
If eclipse, please use the JUpload code formatting stuff. (I'll check everything is documented enough, which I'm not really sure).

Etienne

[Anonymous]

I can submit a patch, but was curious to know what exactly we want the functionality to be. For example, if we have a 100 character URL do we want that to be on a single line or multiple? My quick fix for work was just to wrap the text at a specific character length without regard to whether I broke up a word (probably not the best solution). So, I think we should try to keep the words together and thus some lines may contain less characters than what we specify as the max limit.

Also, how do we want to handle URLs? If there is a 200 character URL and if the max character length is 100, then should we keep the URL intact or split it onto 2 lines?

Let me know how you would like this to work. I'll try to prepare something for you and submit the patch for review.

[Anonymous]

Proposed patch for issue

[Nobody/Anonymous]

Hi,

All information should be available in the log, which should not be formatted.

So, I think the only real objective here is to present an understandable information to the user. Which gives:
1) having word wrap, if possible
2) Too long URL replaced by http:/qdqd.qdqd.com/TheVeryLongPathTruncated...

Etienne

[Etienne]

Was fixed a long time ago