LSL エラー

/ja

Run-time error messages

スクリプトは実行中に停止し、以下のようなメッセージと共に"Script run-time error"をあなたに伝えるかもしれません。

Script run-time error: Heap Error

無意味な事をしないでください。例えば、結果を返さないルーチンでリスト型を返さないでください。

Script run-time error: Lists may not contain lists

リスト内にリストを入れることはできません。

Script run-time error: Math Error

Float型の数値を0で割ろうとした、integer型の数値を0で割ろうとした、等。

Script run-time error: Stack-Heap Collision

スタック領域がバイトコード領域やヒープ領域に衝突した。

それぞれのスクリプトは、16キロバイトに分割されたメモリ内で実行されます。そのメモリはバイトコード領域、スタック領域、ヒープ領域に分割されています。

あなたが長すぎるスクリプトを書いてコンパイルすると、大きすぎるバイトコードが生成され、衝突が発生します。 スクリプトがコンパイルできてセーブに成功したとしても、スクリプトを含んだオブジェクトを rez しようとすると、スクリプトはすぐに、あるいは実行中にクラッシュします。

See llGetFreeMemory.

Run-time error demo scripts

ランタイム･エラーを経験するために、以下の例のコンパイルして実行してください。

<lsl> default {

   state_entry()
   {
       llOwnerSay((string) [llOwnerSay("bye")]); // Script run-time error: Heap Error
   }

} </lsl>

<lsl> default {

   state_entry()
   {
       list once = [];
       list twice = [once, once]; // Script run-time error: Lists may not contain lists
   }

} </lsl>

<lsl> default {

   state_entry()
   {
       float one = 1.0;
       float zero = 0.0;
       float quotient = one / zero; // Script run-time error: Math Error
       llOwnerSay((string) quotient);
   }

} </lsl>

<lsl> default {

   state_entry()
   {
       list entries = [0];
       while (TRUE)
       {
           entries += entries; // Script run-time error: Stack-Heap Collision
           llOwnerSay((string) llGetListLength(entries));
       }
   }

} </lsl>

Compile-time error messages

The SL GUI はあなたが完璧だと思ったいくつかのコードを拒絶し、いくつかの説明と共にERRORを出力するかもしれません。

ERROR : Type mismatch

vector型やrotation型に値を指定するには、 .x .y .z .s という名の要素を使わなければなりません。一度にlistで指定することはできません。例えば:

<lsl> default {

   state_entry()
   {
       vector vec = (vector) [1, 2, 3]; // ERROR : Type mismatch
       llOwnerSay((string) vec);
   }

} </lsl>

ERROR : Byte code assembly failed -- out of memory

スクリプトは、ほどよく小さく(reasonably small)書かなければなりません。

例えば、あまりにも多くのelse-ifを並べた場合、コンパイラはスクリプトが大きすぎると報告します。 <lsl> demoElseIfCompileError(integer count) {

   if (count == 0)
   {
       ;
   }
   else if (count == 1)
   {
       ;
   }
   else if (count == 2)
   {
       ;
   }
   ...
   ... // ERROR : Byte code assembly failed -- out of memory
   ... // or ERROR : Syntax error
   ...
   else if (count == ...)
   {
       ;
   }

} </lsl>

どのくらいのスクリプトが大きすぎるスクリプトなのかは、驚くほど変化することがあります。例えば、the 2007-08 Second Life クライアントでは30倍程度に変化しました。具体的には、Windowsクライアントは22個のelse-ifを受け付け、23個のelse-ifを拒絶しましたが、Mac OS Xは692個のelse-ifを受け付け、693個のelse-ifを拒絶しました。

OSによって変化するコンパイラの制限は、コピー制限の手段のように働きます。制限のゆるいコンパイラでコンパイルされたスクリプトを誰でも実行できます。しかし、制限の多いコンパイラしか持たないユーザは、そのソースを変更してもセーブできません。

See llGetFreeMemory, llMessageLinked.

ERROR : Syntax error

もちろんあなたはスクリプトやスクリプト内の語をコンパイラが受け入れられるように厳密に記述しなければなりません。

そして、スクリプトをほどよく小さく書かなければなりません。あまりに大きなスクリプトを書いた場合、コンパイラは"out of memory(メモリあふれ)" や "byte code assembly failed(バイトコード生成に失敗)"のような丁寧で明確なエラーではなく、 "syntax" error(構文エラー)だと報告するかもしれません。

例えば、2007-08年のWindows版のSecond Lifeクライアントは多くのelse-ifを並べるとSyntax error(構文エラー)を報告します。厳密な制限数は驚くほど変化します。例えば、2007-08年のWindows版のSecond Lifeクライアントは、あるときは22個以上並べたelse-ifを受け入れましたが、あるときはスクリプトの他の詳細な記述によって19個以下に並べたelse-ifを拒絶しました。

1つのコンパイラでLSLを学ぶプログラマは、コンパイラの制限は合理的(reasonable)なものだと感じるかもしれません。例えば、Mac OS Xでは500個までのelse-ifを並べることができます。しかし別なコンパイラを使うプログラマはそうではなく、大きく異なる制限値だけが合理的だと感じるかもしれません。例えば、Windowsではelse-ifを並べられるのはせいぜい1ダースだと感じるかもしれません。