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 2 of 2 — ← Prev page 1 [2]

#34637

Reference:
When you throw an exception from 'main' you cannot handle it. Unhandled exceptions are an antipattern, for example because they lead to bad user experiences and throw program state into lala-land. Ergo throwing exceptions from 'main' is an antipattern. Q.E.D.

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

#34649

Tue, 14 Jun 2016 12:52:15 -0700 (PDT), /Lew/:

> Reference:
> When you throw an exception from 'main' you cannot handle it.

Eric Sosman already gave an example where you can, and you would 
need to handle exceptions from 'main' – when you call main() vs. 
java calling it from the command prompt.  Handling the exception 
would not be possible if you call System.exit() from main(), for 
comparison.

> Unhandled exceptions are an antipattern, for example because they
> lead to bad user experiences and throw program state into lala-land.

I don't think the later is any argument.  The "lala-land" state 
should be handled by using proper finally, try-with-resources 
blocks, etc. deeper in the implementation of the program.  The 
main() method could not possibly know all details it might need to 
handle.

"Bad user experience" is rather subjective and java is reporting the 
exceptions just fine.  If your specific program needs something more 
– then go ahead and implement it.  For extra logging and else I 
believe one should be able to set up JVM, or just main thread 
shutdown hooks.

The only case System.exit() would need to be used is when your 
program needs to report many well documented exit codes, which is 
still specific use case.

> Ergo throwing exceptions from 'main' is an antipattern. Q.E.D.

Still sounds non-sense to me.

-- 
Stanimir

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

#34654

On Tuesday, June 14, 2016 at 4:46:31 PM UTC-7, Stanimir Stamenkov wrote:
> Tue, 14 Jun 2016 12:52:15 -0700 (PDT), /Lew/:
> 
> > Reference:
> > When you throw an exception from 'main' you cannot handle it.
> 
> Eric Sosman already gave an example where you can, and you would 
> need to handle exceptions from 'main' – when you call main() vs. 
> java calling it from the command prompt.  Handling the exception 

That's not advisable. 'main' exists for the purpose of being an entry point. Using it for other purposes is not good.

> would not be possible if you call System.exit() from main(), for 
> comparison.

Moot, because you shouldn't be calling 'main' except as an entry point.

> > Unhandled exceptions are an antipattern, for example because they
> > lead to bad user experiences and throw program state into lala-land.
> 
> I don't think the later is any argument.  The "lala-land" state 
> should be handled by using proper finally, try-with-resources 
> blocks, etc. deeper in the implementation of the program.  The 

Which is not possible when 'main' is the entry point.

> main() method could not possibly know all details it might need to 
> handle.

It is not the job of 'main' to "know" all the details that exist. It is necessary that 'main' handle all the details exposed to it, just like in any method. For 'main' to throw an exception is for it to abdicate its responsibilities.

> "Bad user experience" is rather subjective and java n[sic] is reporting the 

Not so. There are absolutely well-defined engineering principles behind "bad" and "good" user experiences. You should learn about them.

> exceptions just fine.  If your specific program needs something more 
> – then go ahead and implement it.  For extra logging and else I 
> believe one should be able to set up JVM, or just main thread 
> shutdown hooks.

Bad design. Abdicating responsibility for program state leads to unexpected bugs, for example. Study any best practices around exceptions and ignoring them is always excoriated for solid engineering reasons. You should learn about them.

> The only case System.exit() would need to be used is when your 
> program needs to report many well documented exit codes, which is 
> still specific use case.
> 
> > Ergo throwing exceptions from 'main' is an antipattern. Q.E.D.
> 
> Still sounds non-sense [sic] to me.

And yet it is consistent with well-established best practices that are promulgated by acknowledged authorities in software development.

Given that your argument depends on abusing 'main' for improper purposes, it does not establish your conclusion.

-- 
Lew

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

#34657

On Wed, 15 Jun 2016 02:46:25 +0300, Stanimir Stamenkov wrote:

> Tue, 14 Jun 2016 12:52:15 -0700 (PDT), /Lew/:
> 
>> Reference:
>> When you throw an exception from 'main' you cannot handle it.
> 
> Eric Sosman already gave an example where you can, and you would need to
> handle exceptions from 'main' – when you call main() vs. java calling it
> from the command prompt.  Handling the exception would not be possible
> if you call System.exit() from main(), for comparison.
> 
>> Unhandled exceptions are an antipattern, for example because they lead
>> to bad user experiences and throw program state into lala-land.
> 
> I don't think the later is any argument.  The "lala-land" state should
> be handled by using proper finally, try-with-resources blocks, etc.
> deeper in the implementation of the program.  The main() method could
> not possibly know all details it might need to handle.
> 
> "Bad user experience" is rather subjective and java is reporting the
> exceptions just fine.  If your specific program needs something more –
> then go ahead and implement it.  For extra logging and else I believe
> one should be able to set up JVM, or just main thread shutdown hooks.
> 
> The only case System.exit() would need to be used is when your program
> needs to report many well documented exit codes, which is still specific
> use case.
> 
>> Ergo throwing exceptions from 'main' is an antipattern. Q.E.D.
> 
> Still sounds non-sense to me.

I prefer to use a run() method for running the code as part of a larger 
prcess and reserving the main() method for use only when the class is 
being run as a free-standing process:

public static void run(String args[]) throws Throwable
{
   /* 
      Top-level code that does stuff that the class was written to do
      and throws a Throwable if it fails.
   */
   ....
}

public static void main (String args[])
{
   try
   {
      run(args);
   }
   catch (Throwable t)
   {
      System.err.println("Error: " + t.getMessage());
   } 
}

If the class is part of a program suite with all its components in the 
same jarfile, then I omit the main() method and introduce a 'launcher' 
class. This is declared as the main class in the manifest. Its only job 
is to load the selected top-level program class, call its run() method 
and do any required clean-up after run() has ended. Needless to say, 
these programs are all subclasses of the same superclass and, in some 
cases there may be preliminaries, such as parsing a common configuration 
file, that are best done by the launcher class. 


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

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

#34658

On 6/15/2016 9:17 PM, Martin Gregorie wrote:
> [...]
> public static void run(String args[]) throws Throwable
> {
>    /*
>       Top-level code that does stuff that the class was written to do
>       and throws a Throwable if it fails.
>    */
>    ....
> }
>
> public static void main (String args[])
> {
>    try
>    {
>       run(args);
>    }
>    catch (Throwable t)
>    {
>       System.err.println("Error: " + t.getMessage());
>    }
> }

     I do not understand why anyone would consider this an improvement
over simply throwing the damn' Throwable.  It does almost the same
thing as throwing the Throwable: print a message and terminate the call
to main.  True, the termination is not "abrupt," because main actually 
returns instead of exiting via the throw.  Still, it's a termination.

     But then, there's the rest of the "almost:"

	THE SUPPOSED IMPROVEMENT SUPPRESSES VITAL INFORMATION!!!

(Hint: Where is the stack trace you *would* have seen had the GODDAM
STOOPID MISBEGOTTEN IMBECILIC[*] try/catch not bit-bucketed it?)

     [*] (Off my medications, will resume them when/if I get rational.)

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

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

#34660

On Wed, 15 Jun 2016 21:56:58 -0400, Eric Sosman wrote:

> (Hint: Where is the stack trace you *would* have seen had the GODDAM
> STOOPID MISBEGOTTEN IMBECILIC[*] try/catch not bit-bucketed it?)
> 
>      [*] (Off my medications, will resume them when/if I get rational.)
>
I don't find a stack dump as useful as the output from a diagnostic/
tracing system I wrote that gets included in most of my code and left 
there after development is finished. Its controllable for the amount of 
tracing detail it outputs and has the ability to capture a configurable 
number of trace messages in a circular buffer and dump them when an error 
is reported.

You can blame my exposure to both the Algol68R compiler and runtime 
system for the tracing style and ICL's George 3 OS for the circular 
buffers:

- if an Algol68R program crashed it produced the most marvellous 
diagnostic report. This showed all currently active variables and their 
contents together with the run history showing not only the procedure 
call stack but the execution path taken through them, something like:

   PROC myproc(arg="cat") called
   int n = 23
   Line 4 - if.. else
   Line 12 - if..then
   Line 34 For executed 8 times
   ....

- When George 3 came unstuck it dumped two circular buffers, one showing 
the last 100 code modules executed and the other showing the last 100 
checkpoints in those modules.  

Both systems made problem diagnosis very simple. Combining them allows me 
to use fairly detailed tracing when bug hunting in a long-running program 
without getting buried in megabytes of trace log: setting the buffer size 
to 100-200 trace points is usually enough to show where a program crashed 
and what earlier event caused the crash.


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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web