Exception Handling bei EBC

[Schueh]

Hallo Zusammen

In der aktuellen dotnetpro 10/2011 hat Ralf einen interessanten
Artikel über EBC geschrieben. Unter anderem geht es auch um das
Exception Handling bei synchronen und asynchronen Flüssen. So wie ich
das richtig verstanden habe, definiert man bei einzelnen Bauteilen
zusätzlich einen Output Pin für die Exception, ist das richtig? Hat
hier jemand konkrete Code-Beispiele?

Ich freue mich auf euer Feedback.

[janekf]

Hallo,

irgendwo in diesem Forum hatten wir dieses Thema schon einmal. Aber im
Prinzip ist es recht einfach, indem du ein Output anlegst, mit dem
Actionparameter Exception

public Action<Exception> OnException;

Im Falle einer Exception kannst du dann einfach

OnException(ex)

aufrufen. Natürlich innerhalb der EBC.

Gruß
Janek

[pbedat]

Hi,

Bei mir hat jedes Bauteil einen standard Error Ausgang. Die einfachen
FUs leiten sich dabei immer von der "ComponentBase" ab.

Beispiel:

class Count_Uppercase_Characters : ComponentBase<string, int>,
ICount_Uppercase_Characters
{
public override int Process(string msg)
{
if(msg == null)
throw new YourCustomException();
// implementation...
}
}

Meine einfachen Bauteile bieten immer eine Input Methode und eine
Output Action, die über ComponentBase implementiert werden.

Die Input Methode:

public TOut Input(TIn msg)
{
//common validation logic (depencies, config, etc.)

try
{
Output(Process(msg));
}
catch(Exception e)
{
OnError(e);
}
}

Gruß,
Patrick

On 3 Okt., 12:22, Schueh <manuel.sid...@gmx.ch> wrote:

[chrkon]

Hallo Patrick,

mit dem TryCatch Block behandelst Du die Exception aber an einer
Stelle, an der Du eventuell nicht alle Informationen hast, die Du für
eine vernünftige Fehlerbearbeitung benötigst. Wenn man die Exception
über einen eigenen Pin ausgibt, kann man sehr flexibel darauf
reagieren. Das geht dann auch außerhalb der eigentlichen
Funktionseinheit!

Beispiel:
a) Zahl eingeben.out_Result > (int) > Join.in_A
b) Zahl eingeben.out_Result > (int) > Join.in_B

c) Join.out > (Tupel(int,int) ) > Dividiere.in_Term

d) Dividiere.out_result > (double) > Anzeige.in_Ergebnis
e) Dividiere.out_Error > (Exception) > Fehlermeldung.in_Fehler > () >
WarteAufTaste.in_wait
f) WarteAufTaste.out_proceed > () > Zahl eingeben.Process() > weiter
bei b)

Viele Grüße,
Christof

[pbedat]

Hi Christof,

Genau das mache ich doch ;)

Gruß,
Patrick

[chrkon]

Hmm, nachdem ich mir die Antwort von Patrick noch mal angeschaut habe,
denke ich, dass er im Grunde das gleiche meint, wie ich. Ich war nur
irritiert, weil ich den Error Ausgang im Beispiel code nicht gesehen
habe. Aber erschreibt ja, dass dieser in der Component Base Klasse
angelegt wird.

Ich selber halte die Funktionseinheiten so klein und so unabhängig wie
möglich. Daher verwende ich (unter c#) keine Basisklasse, sonders
definiere alle Input und Output Pins in dem entsprechenden Interface.
Hier ein Beispiel aus meinem DeviceSimulator Projekt:

using System;

namespace CK.DevSim.Contracts
{
public interface IConvertControlBytes
{
void in_EncodeString(string text);
event Action<string> out_EncodedString;
void in_DecodeString(string text);
event Action<string> out_DecodedString;
event Action<Exception> out_Error;
}
}

In dieser Funktionseinheit werden Sonderzeichen im String in lesbare
String umgewandelt und umgekehrt. (z.B. ASCII 13 <> [CR] oder ASCII 06
<> [ACK])

Viele Grüße,
Christof

[pbedat]

Die ComponentBase Klasse darfst du nicht als Abhängigkeit betrachten.
Ich verwende ja auch Contracts.
ComponentBase ist quasi ein Tool, das ich verwende und quasi nur die
EBC Infrastruktur kapselt.
Die FU die ich implementiere enthält nur die Essenz und zwar die
Funktionalität in Form der Process Funktion.

[Olaf Krumnow]

Ich bin davon ab, die Exceptions direkt im Baustein zu behandeln und
an einen Pin zu signalisieren. Den Grund habe ich hier dargelegt:
http://blog.jebc.de/2011/07/probleme-mit-den-checked-exceptions/

Ist zwar für Java, aber den Bildern sieht man's nicht an.

Stattdessen habe ich explizite Exception-Parts, die ich an passender
Stelle in den Fluss einbaue.

Gruß
Olaf