The UIManager.setLookAndFeel method throws a specific exception (that is, UnsupportedLookAndFeelException). The throws Exception clause hides this from the users of your method - anyone who call your method will be forced by the compiler to handle (catch or declare throws) an Exception. The Exception can be nearly anything - IOException, SQLException, ClassNotFoundException or perhaps fifty other possibilities. How will you handle such an unspecific exception?
You could let the method throw UnsupportedLookAndFeelException - that way the caller might decide what to do when the exception is thrown - perhaps show an error message, perhaps terminate the application, perhaps just ignore it. Or you might handle the exception in the form itself and decide there what to do if the look and feel cannot be set.
A completely different thing is whether one concrete from should decide what the look and feel of an entire application looks like - I'd say it shouldn't, the look and feel should be set somewhere at the application startup. But this case is not so clearly cut - perhaps this approach could be valid in some situations.
What you have done is declare a checked Exception, in a fully implemented constructor. That means every time you invoke that constructor, probably even as super(), it has to be inside a try (or a method with throws). Is there any evidence that initComponents() or set look & feel methods throw Exceptions? Plain simple throws Exception is a bit too definite for my likings.
Plain simple throws Exception is a bit too indefinite for my likings. If you know about a certain Exception, then declare that Exception. It is better to declare throws XYZException if you might suffer an XYZException. Then users of the class know what to expect.
So I don’t think it is good design. No.
Unchecked Exceptions, if there is of a throw new ABCDException(); statement, should be declared with @throws tags in the documentation comments.
In that particular situation? The probability of an exception being thrown by that code is for all practical purposes zero. (It can only happen if there's a problem with the system look-and-feel.) So I would (and did, in code that I wrote) simply wrap a try-catch block around the line of code which throws the exception, and ignore any exception which gets thrown.
But since we're talking about good programming practice, you should still at least log the exceptions which won't ever be thrown. (Which I didn't, in my code.)