Proposal for Implementing a Global Exception Handler and Logging

[manufino]

I would like to propose an improvement in our exception handling to ensure that all exceptions, both handled and unhandled, are properly captured and logged. Here’s the idea:

Currently, unhandled exceptions can go unnoticed, especially if they occur in non-EDT (non-Event Dispatch Thread) threads or if they are caught but not logged. This can make debugging and diagnosing issues.

Global Exception Handler:

Thread.setDefaultUncaughtExceptionHandler: Configure this handler to capture all unhandled exceptions in non-EDT threads. This will allow us to log any exception that escapes standard checks in these threads.
Swing EventQueue Management: Set up a specific handler for the EDT, which is the main thread where UI operations occur. This way, we can intercept all unhandled exceptions that occur during user interface interactions.

Custom Exception Class for Logging:

Create a custom exception class that automatically logs every exception at the time of its creation. This ensures that even exceptions caught in try-catch blocks will be automatically recorded in a log file without needing to manually add logging code in each block.
This centralized approach will provide a comprehensive view of all exceptions occurring, making it easier to debug and monitor the application.

We could also consider implementing log submission to a server with a custom PHP page, of course, only if the user chooses to send it.

[DarwinNE]

I think it would add a certain degree of complexity but not a lot of real benefits. After all, the end users should not have to deal with those things. The only persons that may be interested to the exceptions would be the developers and we already have the command line and the console.

In my experience, most of the problems I had to solve remotely were issues with Java versions. A nasty bug with Linux graphic subsystem was probably due to graphic drivers and not to FidoCadJ itself.

Communicating with an external server introduces a huge number of issues: where to put the server, who maintains and pays for it, who reads the logs. More importantly it may open the door towards security problems that I do not want to be involved with.

In my opinion, the game is not worth the candle.

[manufino]

Okay, I understand your concerns, but at the very least, having an unhandled exception handler that displays an error message could be useful. This way, they could at least send you a screenshot of the message to help you understand the problem.

Anyway, it’s up to you; I’m fine with whatever you decide.

[DarwinNE]

In principle, unhandled exceptions should not occur very often.
You mean showing a basic message box when they are raised?

[manufino]

Yes, we could capture them using Thread.setDefaultUncaughtExceptionHandler and other techniques, then display them with a message or log them.

[DarwinNE]

Maybe showing them with a message box or something similar would be reasonable and more than enough (the user should be able to copy the text of the exception).

[manufino]

Alright, I'll add it to the to-do list.

[DarwinNE]

Hi,
I noticed a problem with the following code in the main method of src/fidocadj/FidoMain.java

        // Sets an exception handler for the EDT (Event Dispatch Thread)
        try {
            SwingUtilities.invokeAndWait(() -> {
                Thread.currentThread().setUncaughtExceptionHandler(
                        (thread, throwable) -> {
                            handleUncaughtException(thread, throwable);
                        });
            });
        } catch (InterruptedException | InvocationTargetException e) {
            SwingUtilities.invokeLater(() -> {
                JFrame parentFrame = null;
                StringWriter sw = new StringWriter();
                PrintWriter pw = new PrintWriter(sw);
                e.printStackTrace(pw);
                String exceptionText = sw.toString();

                ErrorDialog errorDialog = new ErrorDialog(parentFrame,
                        "Error setting the exception handler for the EDT:\n" +
                                exceptionText);
                errorDialog.setVisible(true);
            });
        }

I think it prevents to run FidoCadJ in the headless mode. I moved it in a section where it is executed only the program should not run on the command line only:

58b992b

Can you check if it is ok?

[manufino]

Okay, I'll check everything in the coming days. Perhaps it would have been enough to encapsulate it in an if statement that checks the mode we're in.