how to raise warning?

[Szymon Drejewicz]

How to raise warning?

 

[Robert Klemme]

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

 

[Simon Strandgaard]

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

server> irb
irb(main):001:0> warn("hello")
hello
=> nil
irb(main):002:0>

 

[Gavin Sinclair]

How to raise warning?

warn "message"

Gavin

 

[Szymon Drejewicz]

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.

 

[Robert Klemme]

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

 

[Andrew Johnson]

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.

The Kernel#caller method gives you the trace information. So you
can redefine Kernel#warn along these lines:

module Kernel
alias ldwarn :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

 

[Szymon Drejewicz]

module Kernel

alias ldwarn :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."

 

[Josef 'Jupp' SCHUGT]

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

 

[Yukihiro Matsumoto]

Hi,

In message "Re: how to raise warning?"

|warn "#{__FILE__}:#{__LINE__}: there is an error"

Do you guys expect "warn" to prepend the place information before the
message?

matz.

 

[Gavin Sinclair]

Hi,

In message "Re: how to raise warning?"

|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

 

[Hal Fulton]

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:
1. 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).
2. 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

 

[Joel VanderWerf]

Hal Fulton wrote:
...

The problem as I see it is that we use warnings in two ways:
1. 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).
2. 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").

 

[Robert Klemme]

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:
1. 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).
2. 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

 

[nobu.nokada]

Hi,

At Fri, 20 Feb 2004 20:53:21 +0900,
Robert Klemme wrote in [ruby-talk:93233]:

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?

 

[Tim Hunter]

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).

My faithful online thesaurus suggests "alert" or "caution" as good,
distinctive synonyms for "warn".

 

[jrb3]

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:
1. 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).
2. 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.

 

[jrb3]

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.

 

[Josef 'Jupp' SCHUGT]

Hi!

* (e-mail address removed):

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

 

[jrb3]

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, :EBUG, ...), 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 ....

^^^^^^^^^

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.