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


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

email from catch or exception

Started byRVic <rvince99@hotmail.com>
First post2013-12-11 14:55 -0800
Last post2013-12-11 19:52 -0500
Articles 16 — 6 participants

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


Contents

  email from catch or exception RVic <rvince99@hotmail.com> - 2013-12-11 14:55 -0800
    Re: email from catch or exception Knute Johnson <september@knutejohnson.com> - 2013-12-11 15:12 -0800
    Re: email from catch or exception Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-12-11 18:13 -0500
      Re: email from catch or exception Arne Vajhøj <arne@vajhoej.dk> - 2013-12-11 19:08 -0500
        Re: email from catch or exception Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-13 12:44 -0400
          Re: email from catch or exception Arne Vajhøj <arne@vajhoej.dk> - 2013-12-14 16:36 -0500
            Re: email from catch or exception Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-15 17:10 -0400
    Re: email from catch or exception RVic <rvince99@hotmail.com> - 2013-12-11 15:23 -0800
      Re: email from catch or exception Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-12-11 21:09 -0500
        Re: email from catch or exception Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-12-11 23:34 -0500
      Re: email from catch or exception leif.roar@invalid.com (Leif Roar Moldskred) - 2013-12-12 00:41 -0600
    Re: email from catch or exception RVic <rvince99@hotmail.com> - 2013-12-11 15:26 -0800
    Re: email from catch or exception Arne Vajhøj <arne@vajhoej.dk> - 2013-12-11 19:06 -0500
    Re: email from catch or exception RVic <rvince99@hotmail.com> - 2013-12-11 16:28 -0800
      Re: email from catch or exception Arne Vajhøj <arne@vajhoej.dk> - 2013-12-11 19:50 -0500
        Re: email from catch or exception Arne Vajhøj <arne@vajhoej.dk> - 2013-12-11 19:52 -0500

#26839 — email from catch or exception

FromRVic <rvince99@hotmail.com>
Date2013-12-11 14:55 -0800
Subjectemail from catch or exception
Message-ID<d330148b-653c-4327-81a4-151de67a9e06@googlegroups.com>
Is anyone aware of a public domain package that can email you on an error, include the stack trace or log, whenever an exception occurs? Thank you, RVic

[toc] | [next] | [standalone]


#26840

FromKnute Johnson <september@knutejohnson.com>
Date2013-12-11 15:12 -0800
Message-ID<l8argh$h81$1@dont-email.me>
In reply to#26839
On 12/11/2013 2:55 PM, RVic wrote:
> Is anyone aware of a public domain package that can email you on an
> error, include the stack trace or log, whenever an exception occurs?
> Thank you, RVic
>

Easy enough to write something.  Look at Java Mail, 
https://java.net/projects/javamail/pages/Home.

-- 

Knute Johnson

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


#26841

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2013-12-11 18:13 -0500
Message-ID<l8aric$hig$1@dont-email.me>
In reply to#26839
On 12/11/2013 5:55 PM, RVic wrote:
> Is anyone aware of a public domain package that can email you on an error, include the stack trace or log, whenever an exception occurs? Thank you, RVic

     I think you'd have to modify the JVM itself to do this.  But
you wouldn't want to: If you got an E-mail for every exception
thrown, you'd drown in E-mail.

     Presumably, what you really want is E-mail about "important"
exceptions, and the hard part is clarifying what "important" means.
Could you describe your use case in more detail?

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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


#26847

FromArne Vajhøj <arne@vajhoej.dk>
Date2013-12-11 19:08 -0500
Message-ID<52a8fe6f$0$300$14726298@news.sunsite.dk>
In reply to#26841
On 12/11/2013 6:13 PM, Eric Sosman wrote:
> On 12/11/2013 5:55 PM, RVic wrote:
>> Is anyone aware of a public domain package that can email you on an
>> error, include the stack trace or log, whenever an exception occurs?
>
>      I think you'd have to modify the JVM itself to do this.  But
> you wouldn't want to: If you got an E-mail for every exception
> thrown, you'd drown in E-mail.
>
>      Presumably, what you really want is E-mail about "important"
> exceptions, and the hard part is clarifying what "important" means.
> Could you describe your use case in more detail?

In theory exceptions should be for exceptional cases meaning
no drowning in emails.

I have seen many apps where your concerns are valid though.

Arne

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


#26882

FromArved Sandstrom <asandstrom2@eastlink.ca>
Date2013-12-13 12:44 -0400
Message-ID<OPGqu.658558$276.305809@fx07.iad>
In reply to#26847
On 12/11/2013 08:08 PM, Arne Vajhøj wrote:
> On 12/11/2013 6:13 PM, Eric Sosman wrote:
>> On 12/11/2013 5:55 PM, RVic wrote:
>>> Is anyone aware of a public domain package that can email you on an
>>> error, include the stack trace or log, whenever an exception occurs?
>>
>>      I think you'd have to modify the JVM itself to do this.  But
>> you wouldn't want to: If you got an E-mail for every exception
>> thrown, you'd drown in E-mail.
>>
>>      Presumably, what you really want is E-mail about "important"
>> exceptions, and the hard part is clarifying what "important" means.
>> Could you describe your use case in more detail?
>
> In theory exceptions should be for exceptional cases meaning
> no drowning in emails.
>
> I have seen many apps where your concerns are valid though.
>
> Arne
>
It's true that exceptions are for exceptional cases. The Java tutorial 
says that:

"An exception is an event, which occurs during the execution of a 
program, that disrupts the normal flow of the program's instructions."

However, as you yourself admit, Arne, there are many apps where there 
are frequent exceptions. And no small number of these apps are actually 
well-designed.

As an example (and this is based on a setup I am familiar with), 
consider an ESB app that mediates between 2 systems: A and B. System A 
is a source of data for system B, but both are unaware of each other, 
and the data must be transformed before it goes into B. The hitch is, 
the ESB app has no ability to do more than very simple validation, and 
System A has a fair bit of bad data, because of human data entry and 
configuration reasons [1]. Hence, System B must validate (because it 
knows what it can accept), and this works OK.

The validation errors must come back to the ESB app, since the ESB app 
is the controlling intelligence. They come back as SOAP faults (Java 
runtime exceptions), which is appropriate.

Furthermore, the ESB app polls System A, and communicates with System B 
using SOAP, every few minutes (this interval being configurable but 
dictated by business requirements).

So the first few months we were getting a few dozen SOAP faults every 
few minutes, so say about 500-1000 every hour, or 10-20 thousand a day.

Thing is, 99 percent of those 10-20 thousand SOAP faults were for the 
same few dozen bad data entries in System A. Sending an email for each 
of those would have overwhelmed the human recipients. We recognized that 
a separate ESB job that ran every 24 hours (and effectively called the 
same intermediary logic) would capture all the problems, and it could 
send out a *single* email that provided a summary of the bad data in 
system A (and why it was bad).

Point being, email notification on errors (as with logging errors to 
file etc) are almost always going to a human being [2]. As such, the 
urgency of an error dictates whether a notification should be sent at 
all, how often an email should be sent, who gets it (human or system), 
the nature of the email content (summary or single event), etc etc.

To wit, for a large percentage of apps I think an "email per exception" 
strategy will lead to drowning in emails. And you can Splunk or 
grep|uniq|cut|cat|paste all that to your hearts's content...essentially 
wasting your time to do what the reporting systems could have done in 
the first place.

AHS

1. The fixes for which, in a unionized and bureaucratic environment, are 
not simple.

2. I suppose you could send a stringified object reference to a CORBA 
client... :-)
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

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


#26900

FromArne Vajhøj <arne@vajhoej.dk>
Date2013-12-14 16:36 -0500
Message-ID<52accf58$0$303$14726298@news.sunsite.dk>
In reply to#26882
On 12/13/2013 11:44 AM, Arved Sandstrom wrote:
> On 12/11/2013 08:08 PM, Arne Vajhøj wrote:
>> On 12/11/2013 6:13 PM, Eric Sosman wrote:
>>> On 12/11/2013 5:55 PM, RVic wrote:
>>>> Is anyone aware of a public domain package that can email you on an
>>>> error, include the stack trace or log, whenever an exception occurs?
>>>
>>>      I think you'd have to modify the JVM itself to do this.  But
>>> you wouldn't want to: If you got an E-mail for every exception
>>> thrown, you'd drown in E-mail.
>>>
>>>      Presumably, what you really want is E-mail about "important"
>>> exceptions, and the hard part is clarifying what "important" means.
>>> Could you describe your use case in more detail?
>>
>> In theory exceptions should be for exceptional cases meaning
>> no drowning in emails.
>>
>> I have seen many apps where your concerns are valid though.
>>
>> Arne
>>
> It's true that exceptions are for exceptional cases. The Java tutorial
> says that:
>
> "An exception is an event, which occurs during the execution of a
> program, that disrupts the normal flow of the program's instructions."
>
> However, as you yourself admit, Arne, there are many apps where there
> are frequent exceptions. And no small number of these apps are actually
> well-designed.
>
> As an example (and this is based on a setup I am familiar with),
> consider an ESB app that mediates between 2 systems: A and B. System A
> is a source of data for system B, but both are unaware of each other,
> and the data must be transformed before it goes into B. The hitch is,
> the ESB app has no ability to do more than very simple validation, and
> System A has a fair bit of bad data, because of human data entry and
> configuration reasons [1]. Hence, System B must validate (because it
> knows what it can accept), and this works OK.
>
> The validation errors must come back to the ESB app, since the ESB app
> is the controlling intelligence. They come back as SOAP faults (Java
> runtime exceptions), which is appropriate.
>
> Furthermore, the ESB app polls System A, and communicates with System B
> using SOAP, every few minutes (this interval being configurable but
> dictated by business requirements).
>
> So the first few months we were getting a few dozen SOAP faults every
> few minutes, so say about 500-1000 every hour, or 10-20 thousand a day.
>
> Thing is, 99 percent of those 10-20 thousand SOAP faults were for the
> same few dozen bad data entries in System A. Sending an email for each
> of those would have overwhelmed the human recipients. We recognized that
> a separate ESB job that ran every 24 hours (and effectively called the
> same intermediary logic) would capture all the problems, and it could
> send out a *single* email that provided a summary of the bad data in
> system A (and why it was bad).
>
> Point being, email notification on errors (as with logging errors to
> file etc) are almost always going to a human being [2]. As such, the
> urgency of an error dictates whether a notification should be sent at
> all, how often an email should be sent, who gets it (human or system),
> the nature of the email content (summary or single event), etc etc.
>
> To wit, for a large percentage of apps I think an "email per exception"
> strategy will lead to drowning in emails. And you can Splunk or
> grep|uniq|cut|cat|paste all that to your hearts's content...essentially
> wasting your time to do what the reporting systems could have done in
> the first place.

Well - I am not convinced that the exception is the right choice
when the data quality is as it is resulting in 10-20 thousand
exceptions per day.

But that type of scenario is seen frequently.

But given the question, then I am not expecting the original
poster to be working on that type of application.

Arne



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


#26938

FromArved Sandstrom <asandstrom2@eastlink.ca>
Date2013-12-15 17:10 -0400
Message-ID<pVoru.622166$uR1.268248@fx19.iad>
In reply to#26900
On 12/14/2013 05:36 PM, Arne Vajhøj wrote:
> On 12/13/2013 11:44 AM, Arved Sandstrom wrote:
>> On 12/11/2013 08:08 PM, Arne Vajhøj wrote:
>>> On 12/11/2013 6:13 PM, Eric Sosman wrote:
>>>> On 12/11/2013 5:55 PM, RVic wrote:
>>>>> Is anyone aware of a public domain package that can email you on an
>>>>> error, include the stack trace or log, whenever an exception occurs?
>>>>
>>>>      I think you'd have to modify the JVM itself to do this.  But
>>>> you wouldn't want to: If you got an E-mail for every exception
>>>> thrown, you'd drown in E-mail.
>>>>
>>>>      Presumably, what you really want is E-mail about "important"
>>>> exceptions, and the hard part is clarifying what "important" means.
>>>> Could you describe your use case in more detail?
>>>
>>> In theory exceptions should be for exceptional cases meaning
>>> no drowning in emails.
>>>
>>> I have seen many apps where your concerns are valid though.
>>>
>>> Arne
>>>
>> It's true that exceptions are for exceptional cases. The Java tutorial
>> says that:
>>
>> "An exception is an event, which occurs during the execution of a
>> program, that disrupts the normal flow of the program's instructions."
>>
>> However, as you yourself admit, Arne, there are many apps where there
>> are frequent exceptions. And no small number of these apps are actually
>> well-designed.
>>
>> As an example (and this is based on a setup I am familiar with),
>> consider an ESB app that mediates between 2 systems: A and B. System A
>> is a source of data for system B, but both are unaware of each other,
>> and the data must be transformed before it goes into B. The hitch is,
>> the ESB app has no ability to do more than very simple validation, and
>> System A has a fair bit of bad data, because of human data entry and
>> configuration reasons [1]. Hence, System B must validate (because it
>> knows what it can accept), and this works OK.
>>
>> The validation errors must come back to the ESB app, since the ESB app
>> is the controlling intelligence. They come back as SOAP faults (Java
>> runtime exceptions), which is appropriate.
>>
>> Furthermore, the ESB app polls System A, and communicates with System B
>> using SOAP, every few minutes (this interval being configurable but
>> dictated by business requirements).
>>
>> So the first few months we were getting a few dozen SOAP faults every
>> few minutes, so say about 500-1000 every hour, or 10-20 thousand a day.
>>
>> Thing is, 99 percent of those 10-20 thousand SOAP faults were for the
>> same few dozen bad data entries in System A. Sending an email for each
>> of those would have overwhelmed the human recipients. We recognized that
>> a separate ESB job that ran every 24 hours (and effectively called the
>> same intermediary logic) would capture all the problems, and it could
>> send out a *single* email that provided a summary of the bad data in
>> system A (and why it was bad).
>>
>> Point being, email notification on errors (as with logging errors to
>> file etc) are almost always going to a human being [2]. As such, the
>> urgency of an error dictates whether a notification should be sent at
>> all, how often an email should be sent, who gets it (human or system),
>> the nature of the email content (summary or single event), etc etc.
>>
>> To wit, for a large percentage of apps I think an "email per exception"
>> strategy will lead to drowning in emails. And you can Splunk or
>> grep|uniq|cut|cat|paste all that to your hearts's content...essentially
>> wasting your time to do what the reporting systems could have done in
>> the first place.
>
> Well - I am not convinced that the exception is the right choice
> when the data quality is as it is resulting in 10-20 thousand
> exceptions per day.

It is however the right choice for SOAP. Altering the body to introduce 
error result codes introduces extra coupling between systems; SOAP 
faults (which translate into Java runtime exceptions) are the standard 
way of handling data validation errors, among other things.

That one system has poor data doesn't change this.

> But that type of scenario is seen frequently.

You betcha. :-)

> But given the question, then I am not expecting the original
> poster to be working on that type of application.
>
> Arne

I'm not convinced that he is or isn't, Arne. The OP seemed to be 
ostensibly OK with handling high volumes of emails...although that may 
be seriously optimistic on his part.

AHS
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

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


#26842

FromRVic <rvince99@hotmail.com>
Date2013-12-11 15:23 -0800
Message-ID<625312cc-d71d-4a95-9b97-095fffe36599@googlegroups.com>
In reply to#26839
On Wednesday, December 11, 2013 5:55:34 PM UTC-5, RVic wrote:
> Is anyone aware of a public domain package that can email you on an error, include the stack trace or log, whenever an exception occurs? Thank you, RVic

Looking to send an email on exceptions that are caught, and a general one for those that are uncaught.

I dont mind if there are a ton of emails!

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


#26852

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2013-12-11 21:09 -0500
Message-ID<l8b5sf$3ta$1@dont-email.me>
In reply to#26842
On 12/11/2013 6:23 PM, RVic wrote:
> On Wednesday, December 11, 2013 5:55:34 PM UTC-5, RVic wrote:
>> Is anyone aware of a public domain package that can email you on an error, include the stack trace or log, whenever an exception occurs? Thank you, RVic
>
> Looking to send an email on exceptions that are caught, and a general one for those that are uncaught.
>
> I dont mind if there are a ton of emails!

     I honestly do not know how many exceptions are thrown each
second in a "typical" Java program.  As I said in another post
I think you'd have to modify the JVM to find out -- or maybe
you could use something in java.lang.instrument, a package I've
never had occasion to unwrap.  Perhaps you should loosen that
ribbon a bit before writing "I want ALL of them!" on your
Christmas list.

     But even if it's only one per second, you'll get 86400 per
day.  Can you read 86400 E-mails in one day?  Can you find the
four "different" stack traces among those 86400?  Remember: You
have ONE second to make up your mind about each of them, if you
don't want to fall behind!  Less, if you're monitoring more than
one Java environment ...  Try this experiment: Turn off all your
spam filters, and opt out of any that your ISP offers, and tell
us how smoothly you deal with the onslaught.

     Another little matter: At a rate of >= 1 E-mail/second, many
mail servers will say "Spammer!" and refuse to cooperate.  What
are the chances that any of the "interesting" E-mails will be
among those that get through before the boom is lowered?

     If you're in a position to write `catch' blocks to separate
the "possibly interesting" from "certainly boring" exceptions,
java.util.logging.Handler has sufficient hooks to spew info to
an agent that will E-mail it.  But ALL exceptions!?  I can't think
of any way (even in principle) to do that with a stock JVM, and
I can't imagine that you'd get anything usable out of it.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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


#26854

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2013-12-11 23:34 -0500
Message-ID<l8bed3$8vo$1@dont-email.me>
In reply to#26852
On 12/11/2013 9:09 PM, Eric Sosman wrote:
> On 12/11/2013 6:23 PM, RVic wrote:
>> On Wednesday, December 11, 2013 5:55:34 PM UTC-5, RVic wrote:
>>> Is anyone aware of a public domain package that can email you on an
>>> error, include the stack trace or log, whenever an exception occurs?
>>> Thank you, RVic
>>
>> Looking to send an email on exceptions that are caught, and a general
>> one for those that are uncaught.
>>
>> I dont mind if there are a ton of emails!
>
>      I honestly do not know how many exceptions are thrown each
> second in a "typical" Java program.  [...]

... but I found a twelve-year-old paper about optimizing both
the exceptional and unexceptional execution paths ("A Study of
Exception Handling and Its Dynamic Optimization in Java," by
Ogasawara, Komatsu, and Nakatani).  It contains a table counting
how many exceptions are thrown by various programs.  Some excerpts:

     - Web browser opening one (2001-vintage) page: 2,892 exceptions
     - MP3 player starting and loading one file: 8,205 exceptions
     - Parse one XML file (size? complexity?): 17,640 exceptions
     - One program in SPECjvm98 (now obsolete): 242,318 exceptions

     Now: Speaking slowly, distinctly, and directly into the
carnation in my buttonhole, explain once again that you "dont
mind if there are a ton of emails."

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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


#26856

Fromleif.roar@invalid.com (Leif Roar Moldskred)
Date2013-12-12 00:41 -0600
Message-ID<Y76dnb8EgrjgxzTPnZ2dnUVZ8uidnZ2d@giganews.com>
In reply to#26842
RVic <rvince99@hotmail.com> wrote:
> 
> Looking to send an email on exceptions that are caught, and a general one for those that are uncaught.
> 
> I dont mind if there are a ton of emails!

What do you do about exceptions in the code that sends e-mails, though?

On a more serious note, _why_ do you want e-mails for every exception?
There might be a better way.


-- 
Leif Roar Moldskred

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


#26843

FromRVic <rvince99@hotmail.com>
Date2013-12-11 15:26 -0800
Message-ID<00058b3f-f0c9-48d4-abb7-b9b318a86b62@googlegroups.com>
In reply to#26839
On Wednesday, December 11, 2013 5:55:34 PM UTC-5, RVic wrote:
> Is anyone aware of a public domain package that can email you on an error, include the stack trace or log, whenever an exception occurs? Thank you, RVic

I thought maybe there was a commons package to do all this relatively simply.

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


#26845

FromArne Vajhøj <arne@vajhoej.dk>
Date2013-12-11 19:06 -0500
Message-ID<52a8fdff$0$300$14726298@news.sunsite.dk>
In reply to#26839
On 12/11/2013 5:55 PM, RVic wrote:
> Is anyone aware of a public domain package that can email you on an
> error, include the stack trace or log, whenever an exception occurs?

Put a log4j logging statement in the catch clause and configure
log4j to use an SMTPAppender.

Arne

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


#26848

FromRVic <rvince99@hotmail.com>
Date2013-12-11 16:28 -0800
Message-ID<98492b47-4c88-4362-a103-4dd62a1b55cf@googlegroups.com>
In reply to#26839
Perfect Arne. I need to find an example of such an appender, but thats exactly what I am looking for. THank you.

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


#26849

FromArne Vajhøj <arne@vajhoej.dk>
Date2013-12-11 19:50 -0500
Message-ID<52a90873$0$303$14726298@news.sunsite.dk>
In reply to#26848
On 12/11/2013 7:28 PM, RVic wrote:
> Perfect Arne. I need to find an example of such an appender, but thats exactly what I am looking for. THank you.

log4j comes with the SMTPAppender.

Arne

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


#26850

FromArne Vajhøj <arne@vajhoej.dk>
Date2013-12-11 19:52 -0500
Message-ID<52a908c7$0$303$14726298@news.sunsite.dk>
In reply to#26849
On 12/11/2013 7:50 PM, Arne Vajhøj wrote:
> On 12/11/2013 7:28 PM, RVic wrote:
>> Perfect Arne. I need to find an example of such an appender, but thats
>> exactly what I am looking for. THank you.
>
> log4j comes with the SMTPAppender.

You only need to configure log4j to use it.

Arne

[toc] | [prev] | [standalone]


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


csiph-web