"Hal Fulton" <hal9000 / hypermetrics.com> schrieb im Newsbeitrag
news:4035B01E.6040509 / hypermetrics.com...
> Gavin Sinclair wrote:
> >>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.
> >
> >
> >
> > 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.

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