Thorsten Froehlich <tho### [at] trfde> wrote:
: To whom?  The 1% of very advanced users who know each and every error
: message POV-Ray can generate?

  Don't tell me that the current behaviour is better. With the current
behaviour you *can't* give reasonable error messages: you can't include
numerical values in the error message, you can't split the error message
into several lines, you can't generate the error message for example by
concatenating strings... Instead of seeing an error message, the user sees
a bunch of POV-Ray SDL code. What good does that do? It also makes the life
of the author of the code harder: If the same error message may happen in
more than one place, he can't use just a string identifier to avoid uselessly
repeating the same string several times.
  In fact, the current behaviour can be even more confusing: As seen in the
example, the user doesn't even see the "#error" keyword if the original code
is split into several lines. Thus the user may not know that it was an #error
command which caused the problem but could think that it is something else.

  If it's such a big deal that the user MUST NOT in any circumstance think
that the error message was generated by POV-Ray itself, then make it clear
by adding something to the messages around the error message string itself,
but allow the maker of the include file to be able to print proper error
messages and not just POV-Ray SDL code to the user. The SDL code doesn't
help the user.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message