2016-10-11 16 views
0

エラーがスローされると、Netbeansが出力全体を混乱させることに気付きました。これは、このincomprehensive混乱のような出力を見て作る:代わりに1が期待するもののNetbeans 8.1&Java:エラーがスローされたときに出力がうまく表示されない

Pushing elements onto doubleStack 
1.1 2.2 3.3 4.4 5.5 6.6 
Exceptions.FullStackException: Stack is full, cannot push 6.6 

Popping elements from doubleStack 
5.5 4.4 3.3 2.2 1.1 

    at domein.Stack.push(Stack.java:37) 
Pushing elements onto integerStack 
    at StackApplicatie2.testPush(StackApplicatie2.java:40) 
1 2 3 4 5 6 7 8 9 10 11 

    at StackApplicatie2.testStacks(StackApplicatie2.java:24) 
Popping elements from integerStack 
    at StackApplicatie2.main(StackApplicatie2.java:75) 
<etc. …> 

Pushing elements onto doubleStack 
1.1 2.2 3.3 4.4 5.5 6.6 
Exceptions.FullStackException: Stack is full, cannot push 6.6 
    at domein.Stack.push(Stack.java:37) 
    at StackApplicatie2.testPush(StackApplicatie2.java:40) 
    at StackApplicatie2.testStacks(StackApplicatie2.java:24) 
    at StackApplicatie2.main(StackApplicatie2.java:75) 

Popping elements from doubleStack 
5.5 4.4 3.3 2.2 1.1 

Pushing elements onto integerStack 
1 2 3 4 5 6 7 8 9 10 11 

Popping elements from integerStack 
<etc. …> 

私は思っていた:Netbeansの8.1は、このような奇妙な出力に含まを与えたりしないようにするために、これは正常です?

答えて

0

exception.printStackTrace()を使用すると、スタックトレースはSystem.errに出力されます。自分のメッセージはSystem.outに印刷されています(おそらく)。どちらもバッファリングされたストリームであり、それらのストリームがフラッシュされたとき(バッファサイズに達したとき、改行など)にのみ、出力が宛先に表示されます。

単純な端末アプリケーションでは、両方のストリームがコンソールに向けられますが、両方のストリームのバッファリングによって、フラッシュがインターリーブできるという効果があり、両方のストリームの出力が混ざり合う可能性があります。

これは、NetBeansに固有のものではありません。

何らかの理由で実際に順序を欲しがっていて、例外スタックトレースをエラーストリームに書きたくない場合は、exception.printStackTrace(System.out)を使用できます。しかし、そうすることは珍しいことに注意してください。例外は例外的でなければならず、通常は「標準出力」には行かないべきです。

関連する問題