How to raise warning?
“Szymon Drejewicz” drejewic@wsisiz.edu.pl schrieb im Newsbeitrag
news:c0vhrk$if$1@portraits.wsisiz.edu.pl…
How to raise warning?
Do you mean:
How to raise an exception? (“raise Exception, msg”)
How to print out a warning? ("$stderr.puts “This is a warning”)
or what?
robert
warn “message”
Gavin
···
On Wednesday, February 18, 2004, 10:24:54 PM, Szymon wrote:
How to raise warning?
“Szymon Drejewicz” drejewic@wsisiz.edu.pl schrieb im Newsbeitrag
news:c0vhrk$if$1@portraits.wsisiz.edu.pl…How to raise warning?
Do you mean:
How to raise an exception? (“raise Exception, msg”)
How to print out a warning? ("$stderr.puts “This is a warning”)
There is also #warn
irb
irb(main):001:0> warn(“hello”)
hello
=> nil
irb(main):002:0>
···
On Wed, 18 Feb 2004 13:39:50 +0100, Robert Klemme wrote:
–
Simon Strandgaard
I need something like ‘weak exception’ raising. “warn ‘message’ " works like
"puts ‘message’”, but I’d like to have line number like I have when I raise
exception.
···
–
Szymon Drejewicz
“Szymon Drejewicz” drejewic@wsisiz.edu.pl schrieb im Newsbeitrag
news:c100nt$p0s$1@portraits.wsisiz.edu.pl…
I need something like ‘weak exception’ raising. "warn ‘message’ " works
like
“puts ‘message’”, but I’d like to have line number like I have when I
raise
exception.
warn “#{FILE}:#{LINE}: there is an error”
robert
The Kernel#caller method gives you the trace information. So you
can redefine Kernel#warn along these lines:
module Kernel
alias :oldwarn :warn
def warn(msg=“”, fulltrace=nil)
trace = caller(1)
where = trace[0].sub(/:in.*/,‘’)
$stderr.puts “#{where}: Warning: #{msg}”
$stderr.puts trace.map {|t| “\tfrom #{t}”} if fulltrace
end
end
regards,
andrew
···
On Wed, 18 Feb 2004 16:35:29 +0100, Szymon Drejewicz drejewic@wsisiz.edu.pl wrote:
I need something like ‘weak exception’ raising. "warn ‘message’ " works like
“puts ‘message’”, but I’d like to have line number like I have when I raise
exception.
Hi!
- Robert Klemme:
warn “#{FILE}:#{LINE}: there is an error”
If it is an error it raises an exception. A warning is used when
there is doubt wether something is wanted:
warn “#{FILE}:#{LINE}: no config file, using defaults”
As a rule of thumb a warning can be replaced by an ‘Are you sure?’
dialog.
Josef ‘Jupp’ SCHUGT
···
–
http://oss.erdfunkstelle.de/ruby/ - German comp.lang.ruby FAQ
http://rubyforge.org/users/jupp/ - Ruby projects at Rubyforge
Hi,
···
In message “Re: how to raise warning?” on 04/02/19, “Robert Klemme” bob.news@gmx.net writes:
warn “#{FILE}:#{LINE}: there is an error”
Do you guys expect “warn” to prepend the place information before the
message?
matz.
module Kernel
alias :oldwarn :warn
def warn(msg=“”, fulltrace=nil)
trace = caller(1)
where = trace[0].sub(/:in.*/,‘’)
$stderr.puts “#{where}: Warning: #{msg}”
$stderr.puts trace.map {|t| “\tfrom #{t}”} if fulltrace
end
end
Yes, this is exactly what I need 
thank you
Now it is possible to use just
warn “Message body”
and ruby adds line number by itself without using redundant syntax like
warn “#{FILE}:#{LINE}: Message body.”
···
–
Szymon Drejewicz
Hi,
warn “#{FILE}:#{LINE}: there is an error”
Do you guys expect “warn” to prepend the place information before the
message?matz.
I don’t. A warning is often a user-level piece of information that does
not warrant file and line information.
Having a variant of ‘warn’ that displays that information would be nice IMO.
warn “You didn’t provide such and such”, true
Not perfect, but not bad.
Gavin
···
In message “Re: how to raise warning?” > on 04/02/19, “Robert Klemme” bob.news@gmx.net writes:
Gavin Sinclair wrote:
Hi,
warn “#{FILE}:#{LINE}: there is an error”
Do you guys expect “warn” to prepend the place information before the
message?matz.I don’t. A warning is often a user-level piece of information that does
not warrant file and line information.Having a variant of ‘warn’ that displays that information would be nice IMO.
warn “You didn’t provide such and such”, true
Mmm. I would expect that just to print ‘true’ after the warning.
The problem as I see it is that we use warnings in two ways:
- As Ruby does, to complain about something happening at a specific
place in the source – a highly source-related message. In that
case, I’d want to see file/line info (as Ruby does when it says I
need to add parens or something). - To complain about some general condition occurring at runtime that
doesn’t warrant bailing out of the app.
My suggestion: Two names. Call the first one “warning” (the kind of
warning that Ruby gives us) and the second one “warn” (a simple verb
that just prints to stderr).
Hal
···
In message “Re: how to raise warning?” >> on 04/02/19, “Robert Klemme” bob.news@gmx.net writes:
Hal Fulton wrote:
…
The problem as I see it is that we use warnings in two ways:
- As Ruby does, to complain about something happening at a specific
place in the source – a highly source-related message. In that
case, I’d want to see file/line info (as Ruby does when it says I
need to add parens or something).- To complain about some general condition occurring at runtime that
doesn’t warrant bailing out of the app.My suggestion: Two names. Call the first one “warning” (the kind of
warning that Ruby gives us) and the second one “warn” (a simple verb
that just prints to stderr).
If we were talking about exceptions, the distinction between 1 and 2
would be the distinction between ScriptError and StandardError. Maybe
there should be Warning classes, analogous with Exception classes? This
would give us the flexibility of saying which Warning classes we want to
be reported (“ruby --ignore-warning=ScriptWarning”).
“Hal Fulton” hal9000@hypermetrics.com schrieb im Newsbeitrag
news:4035B01E.6040509@hypermetrics.com…
Gavin Sinclair wrote:
Hi,
warn “#{FILE}:#{LINE}: there is an error”
Do you guys expect “warn” to prepend the place information before the
message?matz.
I don’t. A warning is often a user-level piece of information that
does
not warrant file and line information.Having a variant of ‘warn’ that displays that information would be
nice IMO.warn “You didn’t provide such and such”, true
Mmm. I would expect that just to print ‘true’ after the warning.
The problem as I see it is that we use warnings in two ways:
- As Ruby does, to complain about something happening at a specific
place in the source – a highly source-related message. In that
case, I’d want to see file/line info (as Ruby does when it says I
need to add parens or something).- To complain about some general condition occurring at runtime that
doesn’t warrant bailing out of the app.
Good analysis!
My suggestion: Two names. Call the first one “warning” (the kind of
warning that Ruby gives us) and the second one “warn” (a simple verb
that just prints to stderr).
I like the suggestion, but I’m not fully satisfied with the naming. They
are too similar and thus too easy to confuse. Trying to think of
something better… What about leaving “warn” as it is (i.e. no info on
location) and one of “report” or “source_warn” for a message with file and
line info? This way, no existing code would be broken and we had a clear
naming distinction.
Regards
robert
···
In message “Re: how to raise warning?” > >> on 04/02/19, “Robert Klemme” bob.news@gmx.net writes:
My faithful online thesaurus suggests “alert” or “caution” as good,
distinctive synonyms for “warn”.
···
On Fri, 20 Feb 2004 15:58:48 +0900, Hal Fulton hal9000@hypermetrics.com wrote:
My suggestion: Two names. Call the first one “warning” (the kind of
warning that Ruby gives us) and the second one “warn” (a simple verb
that just prints to stderr).
I don’t. A warning is often a user-level piece of information that does
not warrant file and line information.Having a variant of ‘warn’ that displays that information would be nice
IMO.warn “You didn’t provide such and such”, true
Mmm. I would expect that just to print ‘true’ after the warning.
The problem as I see it is that we use warnings in two ways:
- As Ruby does, to complain about something happening at a specific
place in the source – a highly source-related message. In that
case, I’d want to see file/line info (as Ruby does when it says I
need to add parens or something).- To complain about some general condition occurring at runtime that
doesn’t warrant bailing out of the app.My suggestion: Two names. Call the first one “warning” (the kind of
warning that Ruby gives us) and the second one “warn” (a simple verb
that just prints to stderr).
Well, I use ‘fyi’ for the second (acronym common in the United States
standing for “For Your Information”). Since the application name tends to
be more interesting than the file and line information for the end-user, I
have the application name in the output.
···
def fyi( *message )
puts( "#{}: FYI: " + message.join(‘\n\t’) )
end
fyi “Hi Mom!” “Love you much!”
→
whatYouInvoked: FYI: Hi Mom!
Love you much!
If I really do want the file/line info, I add that into an exception,
throw it, and catch it for display (or logging) elsewhere.
Joseph Beckenbach
lead XP tester, Eidogen Inc.
Hi,
At Fri, 20 Feb 2004 20:53:21 +0900,
Robert Klemme wrote in [ruby-talk:93233]:
My suggestion: Two names. Call the first one “warning” (the kind of
warning that Ruby gives us) and the second one “warn” (a simple verb
that just prints to stderr).I like the suggestion, but I’m not fully satisfied with the naming. They
are too similar and thus too easy to confuse. Trying to think of
something better… What about leaving “warn” as it is (i.e. no info on
location) and one of “report” or “source_warn” for a message with file and
line info? This way, no existing code would be broken and we had a clear
naming distinction.
Doesn’t perl use carp or croak for it?
···
–
Nobu Nakada
Whoops, missing an important part there, sorry …
#!/usr/bin/ruby
ME = File.basename( $0 )
def fyi( *message )
puts( "#{ME}: FYI: " + message.join(‘\n\t’) )
end
fyi “Hi Mom!” “Love you much!”→
whatYouInvoked: FYI: Hi Mom!
Love you much!
Joseph Beckenbach
lead XP tester, Eidogen Inc.
Hi!
Well, I use ‘fyi’ for the second (acronym common in the United
States standing for “For Your Information”).
Actually the above did result in this reaction:
What the hell means ‘fyi’ and why is that an Acron…
Oh I see: ‘FYI’
One is used to read acronyms in all uppercase.
lead XP tester, Eidogen Inc.
^^^^^^^^^
A somewhat off-topic and perhaps stupic question:
I am a bit confused about the term ‘XP tester’. If ‘XP’ stands for
‘eXtreme Programming’ the word ‘XP tester’ rather raises the picture
of a computer that permanently runs test cases. Does the term mean
that you supervise the creation of test cases?
Josef ‘Jupp’ SCHUGT
···
–
http://oss.erdfunkstelle.de/ruby/ - German comp.lang.ruby FAQ
http://rubyforge.org/users/jupp/ - Ruby projects at Rubyforge
Guten tag, Josef Schugt (und freunde)!
(Goodness, has it been that long since my high-school German classes?
One is used to read acronyms in all uppercase.
True, but one must also fit into Ruby idiom. I expect an object's
methods to start lowercase, and all-uppercase symbols to represent
some sort of constant. 'def FYI( *message ) ... ; FYI "yada yada"'
just grates.
Overall, the "warn!" idea seems better for including file/line
information. I might go back to some form where some kind of level is
one of the arguments (eg, ::WARN, ::ERROR, ::FATAL, ::DEBUG, ...), but
I've forgotten or misused (or abused this often enough, that I
prefer to have the method name cite the level of severity. I use so
few as it is ....
lead XP tester, Eidogen Inc.
^^^^^^^^^
A somewhat off-topic and perhaps stupic question:
I am a bit confused about the term 'XP tester'. If 'XP' stands for
'eXtreme Programming' the word 'XP tester' rather raises the picture
of a computer that permanently runs test cases. Does the term mean
that you supervise the creation of test cases?
Yes. In Extreme Programming parlance, I'm part of the 'Customer
team'. I help automate as much of the Customer ("acceptance") tests
as we can. We do have a machine dedicated to continually building our
product, which runs all the unit-tests and a few acceptance tests on
each source-code check-in. Two other machines run a large
acceptance-test suite daily (combined run time around 19 hours). The
team's large enough that it takes a full-time person for this:
actually, it's six developers and two testers so far, and it really
should become closer to 5:3 or 4:4 soon ....
Because I started my career as a releaser, buildmaster, and toolsmith,
I tend to oversee the build machine too. Some days it feels like I'm
not doing much of anything: nothing regressed during the past 24
hours, nothing broke down and needs fixing, and the team just keeps
ticking along steadily adding functionality. That's the norm around
here. I will *not* trade that for any other software job I've worked
at -- we're racheting forward, and everyone has confidence that
they're receiving solid software with the most valuable pieces in
place and usable. Besides, we get home on time, with enough left of
the day for our families, and get in each morning ready to give the
team another good day of work.
Joseph Beckenbach
lead XP tester, Eidogen Inc.