Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34614 > unrolled thread

Could not find or load main class com.mindprod.ensure.Ensure

Back to article view | Back to comp.lang.java.programmer

Contents

  Could not find or load main class com.mindprod.ensure.Ensure Roedy Green <inquiry@mindprod.com> - 2016-06-13 06:51 -0700
    Re: Could not find or load main class com.mindprod.ensure.Ensure Roedy Green <inquiry@mindprod.com> - 2016-06-13 07:02 -0700
      Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Douglas <e.d.programmer@gmail.com> - 2016-06-13 07:15 -0700
    Re: Could not find or load main class com.mindprod.ensure.Ensure Roedy Green <inquiry@mindprod.com> - 2016-06-13 07:35 -0700
      Re: Could not find or load main class com.mindprod.ensure.Ensure Lew <lewbloch@gmail.com> - 2016-06-13 13:48 -0700
        Re: Could not find or load main class com.mindprod.ensure.Ensure Roedy Green <inquiry@mindprod.com> - 2016-06-13 14:11 -0700
        Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-13 20:54 -0400
          Re: Could not find or load main class com.mindprod.ensure.Ensure Arne Vajhøj <arne@vajhoej.dk> - 2016-06-13 21:57 -0400
            Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-13 22:58 -0400
              Re: Could not find or load main class com.mindprod.ensure.Ensure Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-14 10:33 +0000
                Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Douglas <e.d.programmer@gmail.com> - 2016-06-14 04:59 -0700
                  Re: Could not find or load main class com.mindprod.ensure.Ensure Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-14 15:11 +0000
                  Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-14 11:31 -0400
                    Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Douglas <e.d.programmer@gmail.com> - 2016-06-14 09:00 -0700
                      Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-14 13:18 -0400
                        Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Douglas <e.d.programmer@gmail.com> - 2016-06-14 10:38 -0700
                          Re: Could not find or load main class com.mindprod.ensure.Ensure Lew <lewbloch@gmail.com> - 2016-06-14 12:55 -0700
                            Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Douglas <e.d.programmer@gmail.com> - 2016-06-14 13:14 -0700
                              Re: Could not find or load main class com.mindprod.ensure.Ensure Lew <lewbloch@gmail.com> - 2016-06-14 13:34 -0700
                                Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Douglas <e.d.programmer@gmail.com> - 2016-06-14 13:58 -0700
            Re: Could not find or load main class com.mindprod.ensure.Ensure Lew <lewbloch@gmail.com> - 2016-06-14 12:52 -0700
              Re: Could not find or load main class com.mindprod.ensure.Ensure Stanimir Stamenkov <s7an10@netscape.net> - 2016-06-15 02:46 +0300
                Re: Could not find or load main class com.mindprod.ensure.Ensure Lew <lewbloch@gmail.com> - 2016-06-15 12:22 -0700
                Re: Could not find or load main class com.mindprod.ensure.Ensure Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-16 01:17 +0000
                  Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-15 21:56 -0400
                    Re: Could not find or load main class com.mindprod.ensure.Ensure Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-16 11:01 +0000

Page 1 of 2  [1] 2  Next page →

#34614 — Could not find or load main class com.mindprod.ensure.Ensure

I am getting this message when I try to run a very simple program
either via
java -jar ensure.jar
or 
java com.mindprod.ensure.Ensure

Oddly I can run it without trouble inside the IntelliJ IDE.

The manifest looks fine and all the classes needed are in the jar.

have you ever seen this?

Further Jet cannot compile the jar complaining the main class is
missing.

THe main method looks like this

   public static void main( final String[] args ) throws IOException

[toc] | [next] | [standalone]

#34615

On Mon, 13 Jun 2016 06:51:58 -0700, Roedy Green <inquiry@mindprod.com>
wrote:

>   public static void main( final String[] args ) throws IOException

turn out "throws IOException" is the problem. I am pretty sure this
used to work. It stops Java from detecting the main method.

[toc] | [prev] | [next] | [standalone]

#34617

On Monday, June 13, 2016 at 10:02:38 AM UTC-4, Roedy Green wrote:
> turn out "throws IOException" is the problem. I am pretty sure this
> used to work. It stops Java from detecting the main method.

I've never had a problem declaring main to throw anything.

Ideally main shouldn't throw anything, you should want to try catch errors at that level.

[toc] | [prev] | [next] | [standalone]

#34621

On Mon, 13 Jun 2016 06:51:58 -0700, Roedy Green <inquiry@mindprod.com>
wrote:

>
>   public static void main( final String[] args ) throws IOException

something odd.  I have dozens of other programs with a throws that
work fine.

[toc] | [prev] | [next] | [standalone]

#34622

On Monday, June 13, 2016 at 7:35:17 AM UTC-7, Roedy Green wrote:
> On Mon, 13 Jun 2016 06:51:58 -0700, Roedy Green <inquiry@mindprod.com>
> wrote:
> 
> >
> >   public static void main( final String[] args ) throws IOException
> 
> something odd.  I have dozens of other programs with a throws that
> work fine.

Throwing an exception from 'main' is an antipattern.

[toc] | [prev] | [next] | [standalone]

#34623

On Mon, 13 Jun 2016 13:48:48 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote:

>Throwing an exception from 'main' is an antipattern.
I usually only do this in one-shot programs.

[toc] | [prev] | [next] | [standalone]

#34625

On 6/13/2016 4:48 PM, Lew wrote:
>
> Throwing an exception from 'main' is an antipattern.

     Citation?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#34626

On 6/13/2016 8:54 PM, Eric Sosman wrote:
> On 6/13/2016 4:48 PM, Lew wrote:
>> Throwing an exception from 'main' is an antipattern.
>
>     Citation?

I have never seen it catalogued as an anti-pattern.

And it is very common in various demos and adhoc programs.

But for a more serious program I would call it very bad for
a GUI program and a code smell warranting further investigation
of UX and exception handling for a console program.

Arne

[toc] | [prev] | [next] | [standalone]

#34627

On 6/13/2016 9:57 PM, Arne Vajhøj wrote:
> On 6/13/2016 8:54 PM, Eric Sosman wrote:
>> On 6/13/2016 4:48 PM, Lew wrote:
>>> Throwing an exception from 'main' is an antipattern.
>>
>>     Citation?
>
> I have never seen it catalogued as an anti-pattern.
>
> And it is very common in various demos and adhoc programs.
>
> But for a more serious program I would call it very bad for
> a GUI program and a code smell warranting further investigation
> of UX and exception handling for a console program.

     What should the main() of a GUI application do if something
further down the line throws HeadlessException?

     Okay, that's a RuntimeException and perhaps we could fix the
wording to prohibit only the checked exceptions.  But even so: If
main() catches an InterruptedException from something further down,
what action can main() take that would be better than just letting
the IE propagate outward?

	public static void main(String[] args) {
	    try {
	        // "payload" of main()
	    } catch (InterruptedException ex) {
	        LOGGER.severe("I was interrupted!", ex);
	        Thread.currentThread().interrupt();
	        // now what?
	    } catch (Exception ex) {
	        LOGGER.severe("I'm thrown for a loss!", ex);
	        // now what?
	    }
	}

What "constructive" or "useful" steps could be taken in the catch
blocks that would be "better" than letting main() throw the Exception?
In situations where there *is* something better, well sure: Do the
better thing.  But is it a given that something better is possible?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#34628

On Mon, 13 Jun 2016 22:58:44 -0400, Eric Sosman wrote:

>      What should the main() of a GUI application do if something
> further down the line throws HeadlessException?
> 
>      Okay, that's a RuntimeException and perhaps we could fix the
> wording to prohibit only the checked exceptions.  But even so: If main()
> catches an InterruptedException from something further down, what action
> can main() take that would be better than just letting the IE propagate
> outward?
> 
> 	public static void main(String[] args) {
> 	    try {
> 	        // "payload" of main()
> 	    } catch (InterruptedException ex) {
> 	        LOGGER.severe("I was interrupted!", ex);
> 	        Thread.currentThread().interrupt();
> 	        // now what?
> 	    } catch (Exception ex) {
> 	        LOGGER.severe("I'm thrown for a loss!", ex);
> 	        // now what?
> 	    }
> 	}
> 
> What "constructive" or "useful" steps could be taken in the catch blocks
> that would be "better" than letting main() throw the Exception?
> In situations where there *is* something better, well sure: Do the
> better thing.  But is it a given that something better is possible?
>
Your code summarises it pretty nicely. All I'd add is that the user needs 
to know what happened, so if the program uses GUI interface it should log 
the error[1] and report it to the user using a JOptionPane or similar. If 
its a command-line (headless) program it should log the error[1] and 
inform the user by writing one or more lines to System.err. In both cases 
it can simply terminate after its reported what happened.

[1] logging the error is a good idea on systems that support a central 
logging system and can be skipped when running on a system that doesn't. 
The benefit of logging the error as well as telling the user is just that 
the sysadmin has a sporting chance of finding out what really happened if 
the user either doesn't tell anybody or gives a garbled report.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#34629

On Tuesday, June 14, 2016 at 6:34:06 AM UTC-4, Martin Gregorie wrote:
> Your code summarises it pretty nicely. All I'd add is that the user needs 
> to know what happened, so if the program uses GUI interface it should log 
> the error[1] and report it to the user using a JOptionPane or similar. If 
> its a command-line (headless) program it should log the error[1] and 
> inform the user by writing one or more lines to System.err. In both cases 
> it can simply terminate after its reported what happened.

We add an email to IT with a screenshot and full details of the error on all our crash logs.
It's mostly the end user you're worrying about crashing the programs, so aside from notifying IT, it should catch all errors to display a user friendly message, then restart or exit if necessary with as much cleanup as possible.

[toc] | [prev] | [next] | [standalone]

#34630

On Tue, 14 Jun 2016 04:59:20 -0700, Eric Douglas wrote:

> We add an email to IT with a screenshot and full details of the error on
> all our crash logs.
>
Yes, that's a nice approach. 

What I was really getting at is that using the syslog to record problems 
is great if your code is running on Linux. some UNIX flavour or a 
mainframe. The Linux/UNIX logging system is really flexible so you can 
even dedicate a log file series to each production system running on the 
host system and have it automatically mail the day's log messages to the 
relevant sysadmin or maintenance team. Macs should also be able to do 
this since they're essentially running BSD.

However, if your code is running on a PC and you want to capture client 
problems rather than server issues, something like Eric suggests is about 
the best you can do. 
 
> It's mostly the end user you're worrying about crashing the programs, so
> aside from notifying IT, it should catch all errors to display a user
> friendly message, then restart or exit if necessary with as much cleanup
> as possible.
>
I'd hope that code released to end-users couldn't be crashed by them, but 
I know what you mean: how you think users will use a set of screens and 
what they actually do with them can differ quite radically.
 
That said, exactly what you end up doing can be influenced by your user's 
attitude to the system and their background. Example: way back when I 
designed BBC Radio 3's music planning system the users were enthusiastic 
about the system because they'd asked for it. The music planning 
department was largely staffed by musicologists with relevant degrees. 
The system ran on a mainframe. As a consequence, we also gave the music 
planners access to the screen we used to control tracing and debugging 
during development. If they hit a problem we'd talk it over on the phone 
and, if it couldn't be resolved on the spot, we'd ask them to turn on 
tracing, cause the problem again and then turn tracing off. We'd get the 
printout the next day and talk to the planners as soon as we'd decided 
what the problem was and decide how we'd resolve it. Result: everybody 
was happy and we had exactly what we needed to decide what needed to be 
done.
    

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#34631

On 6/14/2016 7:59 AM, Eric Douglas wrote:
> On Tuesday, June 14, 2016 at 6:34:06 AM UTC-4, Martin Gregorie wrote:
>> Your code summarises it pretty nicely. All I'd add is that the user needs
>> to know what happened, so if the program uses GUI interface it should log
>> the error[1] and report it to the user using a JOptionPane or similar. If
>> its a command-line (headless) program it should log the error[1] and
>> inform the user by writing one or more lines to System.err. In both cases
>> it can simply terminate after its reported what happened.
>
> We add an email to IT with a screenshot and full details of the error on all our crash logs.

     (I hope your users "opt in" to this surveillance.  Screen shots may
reveal information the user might have preferred to keep private, as in
the case of Congressional candidate Mike Webb.)

     But back to the original question: After you've logged or reported
or dissected or whatevered the error condition, what next?  Swallow the
exception and System.exit(), or re-throw the exception from main()?  For
myself, I'd find System.exit() noticeably *worse* than throwing, since
it makes your main() harder to call from places other than JVM startup.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#34632

On Tuesday, June 14, 2016 at 11:31:31 AM UTC-4, Eric Sosman wrote:
>      (I hope your users "opt in" to this surveillance.  Screen shots may
> reveal information the user might have preferred to keep private, as in
> the case of Congressional candidate Mike Webb.)

Of course.  This is only in our application which only runs on our internal network.  I expect there's not much in this company that needs to be kept secret from IT.  The only ones who could possibly have such secrets are HR who doesn't use the application and the company president who doesn't use it much.

>      But back to the original question: After you've logged or reported
> or dissected or whatevered the error condition, what next?  Swallow the
> exception and System.exit(), or re-throw the exception from main()?  For
> myself, I'd find System.exit() noticeably *worse* than throwing, since
> it makes your main() harder to call from places other than JVM startup.

Normally we don't crash at the top level, so our application normally allows us to fix a problem and let the user continue.  I expect you should call System.exit() for anything severe enough to throw up to the top level.  At least this is how you're supposed to get the return code if your main class is called from a command prompt.  Otherwise I'm not sure what the difference is between an exit() and throwing an exception from the main().

[toc] | [prev] | [next] | [standalone]

#34634

On 6/14/2016 12:00 PM, Eric Douglas wrote:
> On Tuesday, June 14, 2016 at 11:31:31 AM UTC-4, Eric Sosman wrote:
> [...]
>>      But back to the original question: After you've logged or reported
>> or dissected or whatevered the error condition, what next?  Swallow the
>> exception and System.exit(), or re-throw the exception from main()?  For
>> myself, I'd find System.exit() noticeably *worse* than throwing, since
>> it makes your main() harder to call from places other than JVM startup.
>
> Normally we don't crash at the top level, so our application normally allows us to fix a problem and let the user continue.  I expect you should call System.exit() for anything severe enough to throw up to the top level.  At least this is how you're supposed to get the return code if your main class is called from a command prompt.  Otherwise I'm not sure what the difference is between an exit() and throwing an exception from the main().

     If main() is called from something other than the Java launcher (as
an ordinary method call from another class), that caller could catch a
thrown Exception and maybe do something about it.  But it will have a
harder time if your main() calls System.exit() instead.

     Okay, that could well be called a corner case.  Nonetheless: Before
calling System.exit() you will presumably print the Exception to record
its stack trace for posterity.  What's the difference between "print
stack trace and exit" and "let Java print stack trace and exit?"  How
is the first an improvement?

     I've seen several "We don't do it that way" responses, but haven't
yet seen an argument in support of "Throwing an exception from 'main'
is an antipattern."  *Why* is it an antipattern?  What's the drawback?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#34636

On Tuesday, June 14, 2016 at 1:19:13 PM UTC-4, Eric Sosman wrote:
>      I've seen several "We don't do it that way" responses, but haven't
> yet seen an argument in support of "Throwing an exception from 'main'
> is an antipattern."  *Why* is it an antipattern?  What's the drawback?

Like I said we know the System.exit() is supposed to report a return code out if you called it from a command prompt, so I don't know what code you get if you throw an exception to end the session.  If you don't need that code, normally used for background processes to determine success, throwing the exception could work as well or better.

In many cases it could well be just pot-a-to, pot-ah-to, no different than calling SwingUtilities.invokeLater() versus EventQueue.invokeLater()?  Just the old way and new way of doing essentially the same thing?

[toc] | [prev] | [next] | [standalone]

#34638

"... no different than calling SwingUtilities.invokeLater() versus EventQueue.invokeLater()?  Just the old way and new way of doing essentially the same thing?" No. One of those methods is exactly a wrapper for the other. That is not "essentially" the same thing in Swing, that's literally the same thing.

[toc] | [prev] | [next] | [standalone]

#34640

On Tuesday, June 14, 2016 at 3:55:25 PM UTC-4, Lew wrote:
> "... no different than calling SwingUtilities.invokeLater() versus EventQueue.invokeLater()?  Just the old way and new way of doing essentially the same thing?" No. One of those methods is exactly a wrapper for the other. That is not "essentially" the same thing in Swing, that's literally the same thing.

Point is there's a reason those 2 methods exist.  You don't just write a method that does nothing but call another method.  I believe SwingUtilities came first in an early Java version and is now obsolete, so when they rewrote it into the new package as EventQueue they left the old method for compatibility which now just calls the new one.

So is an exception from main different from System.exit?  It depends on the application.  Is something calling the main that can handle the exception?  Is something running the class that's looking for the exit code?  Did we use to run Java from command line that checked exit codes and now we have a new method to trap exceptions that is replacing the exit code logic which is slowly becoming obsolete?

[toc] | [prev] | [next] | [standalone]

#34642

On Tuesday, June 14, 2016 at 1:14:29 PM UTC-7, Eric Douglas wrote:
> On Tuesday, June 14, 2016 at 3:55:25 PM UTC-4, Lew wrote:
> > "... no different than calling SwingUtilities.invokeLater() versus EventQueue.invokeLater()?  Just the old way and new way of doing essentially the same thing?" No. One of those methods is exactly a wrapper for the other. That is not "essentially" the same thing in Swing, that's literally the same thing.
> 
> Point is there's a reason those 2 methods exist.  You don't just write a method that does nothing but call another method.  I believe SwingUtilities came first in an early Java version and is now obsolete, so when they rewrote it into the new package as EventQueue they left the old method for compatibility which now just calls the new one.

So in other words, they did "just write a method that does nothing but call another method", contradicting what you said in the previous breath and confirming what I said. Thank you for validating my point.

> So is an exception from main different from System.exit?  

Yes, on the face.
And normally one doesn't call System.exit(), either.

> It depends on the application.  Is something calling the main that can handle the exception?  

Rarely, if ever. The purpose of 'main' is to be an entry point (or the entry point), and other uses are contraindicated. So nearly always, the answer is "no", and that's the case to which I'm speaking.

> Is something running the class that's looking for the exit code? 

If so, then for sure throwing an exception is different. In practice, the answer is nearly always "no", so let's solve for that case.

> Did we use [sic] to run Java from command [sic] line that checked exit codes and now we have a new method to trap exceptions that is replacing the exit code logic which is slowly becoming obsolete?

No, we did not and are not.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#34645

On Tuesday, June 14, 2016 at 4:34:42 PM UTC-4, Lew wrote:
> So in other words, they did "just write a method that does nothing but call another method", contradicting what you said in the previous breath and confirming what I said. Thank you for validating my point.

No.  SwingUtilities.invokeLater() calls the EventQueue.invokeLater().  When they first wrote the SwingUtilities, EventQueue did not exist (Java 1.1?).  When they wrote EventQueue they rewrote the SwingUtilities to do nothing but call EventQueue for backwards compatibility only.  If you're writing a new API there's no reason to do that.

> > So is an exception from main different from System.exit?  
> 
> Yes, on the face.
> And normally one doesn't call System.exit(), either.

Yes, normally.  That's the whole point of the discussion.  If your main method gets an error it must handle it or crash.  It is normal to call System.exit(returncode) to pass a value back to a command interpreter running Java as a background process.  It may be called from a batch process where the return code would tell it something useful about the input (wait? try alternate source?) or the output (skip subsequent task? halt production and notify support?).  These days we may have fancier ways to start the Java processes that would make use of the thrown exception instead..

> > It depends on the application.  Is something calling the main that can handle the exception?  
> 
> Rarely, if ever. The purpose of 'main' is to be an entry point (or the entry point), and other uses are contraindicated. So nearly always, the answer is "no", and that's the case to which I'm speaking.
> 
> > Is something running the class that's looking for the exit code? 
> 
> If so, then for sure throwing an exception is different. In practice, the answer is nearly always "no", so let's solve for that case.
> 
> > Did we use [sic] to run Java from command [sic] line that checked exit codes and now we have a new method to trap exceptions that is replacing the exit code logic which is slowly becoming obsolete?
> 
> No, we did not and are not.

So what are you suggesting?  That production code doesn't get errors?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web