AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi Best Practice: Wann verwendet ihr Exceptions in Funktionen?

Best Practice: Wann verwendet ihr Exceptions in Funktionen?

Ein Thema von Zacherl · begonnen am 10. Dez 2013 · letzter Beitrag vom 11. Dez 2013
Antwort Antwort
Seite 3 von 4     123 4   
Furtbichler
(Gast)

n/a Beiträge
 
#21

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 21:04
Die PROCEDURE READNODE kann nicht funktionieren,
weil das Object XmlDoc nicht bekannt ist.
Na ja, die Prozedur könnte eine lokale Prozedur sein, oder XmlDoc ist ein Feld einer Klasse oder eine globale Variable oder es war einfach nur Pseudocode und sollte nur den Sinn von Refactoring und DRY demonstrieren. In jedem Fall hast Du natürlich recht, sie kann nicht funktionieren: Ich habe sie nämlich noch gar nicht gespeichert

Zitat:
Dieser sinnlose VERBESSERUNGSTRIEB
Wenn das für dich sinnlos ist, dann weiß ich auch nicht. Aber jeder soll so programmieren, wie er es für richtig hält. Das Lustige an DRY ist übrigens, das Du die Prozedur 'ReadNode' ohne Probleme anpassen kannst (z.B. den Fehler loggen), und zwar an dieser einen Stelle. Alle Aufrufe werden sich automatisch und logischerweise dann genau gleich verhalten. Bei deiner Copy&Paste-Vorgehensweise müsstest Du dann an allen Stellen das gleiche machen und wehe Du vertippst dich oder vergisst eine Stelle.

Denk mal drüber nach. Und wenn Du schon dabei bist (am Nachdenken), überlege Dir auch noch, ob dich überhaupt jemand kritisiert hat und wieso Du hier so ausrastest. Ich wollte Dir jedenfalls nicht an den Karren pissen.

...dass ich die Methode eher PrintNode
oder 'ProcessNode' oder so.

Das Handle-Beispiel könnte man auch so lösen, das die 'GetHandleFromElsewhere'-Methode die Exception-Behandlung übernimmt. Oder man macht soetwas:

LHandle1 := CheckHandle (GetHandleFromElseWhere, 'From ElseWhere');
LHandle2 := CheckHandle (GetHandleFromElseWhere (LHandle1), 'From ElseWhere 1');
LHandle3 := CheckHandle (GetHandleFromElseWhere (LHandle2), 'From ElseWhere 2');
LHandle4 := CheckHandle (GetHandleFromElseWhere (LHandle3), 'From ElseWhere 3');

...
Wobei das CheckHandle eine Funktion ist:
Delphi-Quellcode:
Function CheckHandle (aHandle : THandle; Msg : String) : THandle;
Begin
  if aHandle = InvalidHandle then Raise Exception.Create(Msg);
  result := aHandle;
End;
Macht Delphi z.T. ja auch so.

Ich persönlich finde das aber nicht sooo lesbar. Es ist zu empfehlen, wenn man die GetXXXX-Funktionen nicht ändern kann.

Man kann die aber Kapseln, sodaß die Exception-Behandlung im Wrapper stattfindet. Solch ein Code (3-Zeiler) kann ruhig komisch aussehen, da schaut man kurz rein, sagt:'Ach so' und macht das Zeugs wieder zu. Die Wrapper sind dann aber sehr gut zu lesen:

Delphi-Quellcode:
Try
  LHandle1 := GetHandle;
  LHandle2 := GetHandle(LHandle1);
  LHandle3 := GetHandle(LHandle2);
  LHandle4 := GetHandle(LHandle3);
  DoSomething(LHandle1,LHandle2,LHandle3,LHandle4);
Except
  On E:EInvalidHandle Do begin
    LogError(E);
    Raise EMoreAbstractException.Create(E);
  End;
End;
Und das ist dann schon wieder schön knackig.
Die 'EMoreAbstractException' analysiert die innere Exception (kann ja unterschiedliche Gründe haben) und erzeugt eine Exception, die die Details verschweigt. Der Aufrufer interessiert sich ja nicht dafür, das der USB-Treiber aufgrund ungültiger Installationsparameter im 3.Duktus links kein Handle bereitstellen kann. Wichtig ist: 'Es funzt net'. Details stehen im Log.

@JasonDX: Wenn da wirklich nur ein Return erfolgen soll, ist das grenzwertig. Meist ist so ein stillschweigendes Scheitern schlechter Stil. WENN es aber genaus so sein soll, ist das mit dem Return schon so richtig.

Da ginge aber auch (besser?) sowas:

Delphi-Quellcode:
if not TryGetHandle (LHandle1) then return;
if not TryGetHandle (LHandle1,LHandle2) then return;
if not TryGetHandle (LHandle2,LHandle3) then return;
if not TryGetHandle (LHandle3,LHandle4) then return;
Wieder knackig kompakt
  Mit Zitat antworten Zitat
Benutzerbild von Meflin
Meflin

Registriert seit: 21. Aug 2003
4.856 Beiträge
 
#22

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 21:15
Für den Fall, dass eine Methode einen Fehlerfall nicht korrekt behandeln kann, sind Exceptions ein valider, sauberer und sinnvoller Weg.
Exceptions sind für mich dann akzeptabel, wenn man andernfalls mehr als einen Rückgabetyp verwenden müsste (geht in statisch getypten Sprachen sowieso nicht) und man keine bessere Alternative hat. Ein Beispiel dafür wäre z.B. eine Try-Klasse. Keine Ahnung, ob es sowas in Delphi gibt. Ist aber auch egal, denn das ist eine "total normale" Klasse und nicht durch spezielle Syntax eingeführt. Wenn man also Try als Typen hat, kann das Ergebnis entweder eine Instanz von Failure oder von Success sein, und beide Wrappen jeweils entweder den Fehler oder das Ergebnis. Muss man nicht gut finden, aber drüber nachdenken kann man ja mal (on a related note: Ich finde auch das procedure-Konzept nicht wirklich sinnvoll )

Exceptions sind mir persönlich einfach zu low level Ich meine, wozu denkt man sich von der technischen Ebene völlig abstrahierte Konzepte wie OOP aus, wenn man dann doch wieder auf etwas zurückgreift, was doch sehr von der Hardware-Ebene inspieriert anmutet (Interrupts...).

Edit: ein anderes Beispiel wäre das Null-Objekt Pattern. Viel schöner als Fehlerbehandlungscode ist doch, wenn man einfach mit den Objekten arbeiten kann, die man als Rückgabe bekommt, und einfach genau das passiert, was passieren soll, wenn man Methoden dieser Objekte aufruft.
Leo S.

Geändert von Meflin (10. Dez 2013 um 21:29 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von JasonDX
JasonDX
(CodeLib-Manager)

Registriert seit: 5. Aug 2004
Ort: München
1.062 Beiträge
 
#23

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 23:05
Exceptions sind für mich dann akzeptabel, wenn man andernfalls mehr als einen Rückgabetyp verwenden müsste (geht in statisch getypten Sprachen sowieso nicht) und man keine bessere Alternative hat. Ein Beispiel dafür wäre z.B. eine Try-Klasse. Keine Ahnung, ob es sowas in Delphi gibt. Ist aber auch egal, denn das ist eine "total normale" Klasse und nicht durch spezielle Syntax eingeführt. Wenn man also Try als Typen hat, kann das Ergebnis entweder eine Instanz von Failure oder von Success sein, und beide Wrappen jeweils entweder den Fehler oder das Ergebnis. Muss man nicht gut finden, aber drüber nachdenken kann man ja mal
Mal abgesehen davon, dass der Code IMO schnell sehr unleserlich wird, was würde denn passieren, wenn ich im Fehlerfall versuche, aufs Success-Objekt zuzugreifen? Krieg ich dann wieder ein Try-Objekt mit Failure? Oder null? (Leider) lässt sich nicht alles aus Funktionalen Sprachen auf objektorientierte oder prozedurale Sprachen mappen. Vor allem wenn die Idee erst schon aus diesen Konzepten kommt und ins Funktionale übertragen wurde.

Exceptions sind mir persönlich einfach zu low level Ich meine, wozu denkt man sich von der technischen Ebene völlig abstrahierte Konzepte wie OOP aus, wenn man dann doch wieder auf etwas zurückgreift, was doch sehr von der Hardware-Ebene inspieriert anmutet (Interrupts...).
Da denkst du einfach nur das Falsche, wenn du an Exceptions denkst. Die haben in ihrer Definition gleich viel mit Interrupts zu tun wie eine Applikation im Lambda-Kalkül mit nem call der CPU.
Ich denke kein Stück an Interrupts wenn ich eine Exception schmeiße, sondern daran, das gerade ein besonderer Fall in meinem Code aufgetreten ist, den ich in meiner derzeitigen Methode nicht behandeln kann.

Edit: ein anderes Beispiel wäre das Null-Objekt Pattern. Viel schöner als Fehlerbehandlungscode ist doch, wenn man einfach mit den Objekten arbeiten kann, die man als Rückgabe bekommt, und einfach genau das passiert, was passieren soll, wenn man Methoden dieser Objekte aufruft.
Das spricht doch eigentlich gegen eine Try-Klasse und für Exceptions nehmen wir an ich habe eine Methode
Code:
parseUrl(String): Url
Wenn ich mit Exceptions arbeite weiß ich, dass wenn ich bspw.
Code:
myUrl = parseUrl(input);
aufrufe und keine Exception geworfen wird (und myUrl somit als zugewiesen gilt), ich in myUrl eine wunderschöne Url-Instanz habe. Wenn ich hingegen eine Try-Klasse oder Fehlermeldungen durch Rückgabewerte oder CallByReference-Parameter verwende, was habe ich dann in myUrl? Vielleicht ne Url, vielleicht aber auch nicht.
Mike
Passion is no replacement for reason
  Mit Zitat antworten Zitat
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#24

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 23:17
Exceptions sind genau das, was sie Aussagen: Ausnahmen.
Genau das wollte ich auch schreiben. Deiner weiteren Erläuterung stimme ich ebenfalls voll zu.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#25

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 23:29
Edit: ein anderes Beispiel wäre das Null-Objekt Pattern. Viel schöner als Fehlerbehandlungscode ist doch, wenn man einfach mit den Objekten arbeiten kann, die man als Rückgabe bekommt, und einfach genau das passiert, was passieren soll, wenn man Methoden dieser Objekte aufruft.
Das spricht doch eigentlich gegen eine Try-Klasse und für Exceptions nehmen wir an ich habe eine Methode
Code:
parseUrl(String): Url
Wenn ich mit Exceptions arbeite weiß ich, dass wenn ich bspw.
Code:
myUrl = parseUrl(input);
aufrufe und keine Exception geworfen wird (und myUrl somit als zugewiesen gilt), ich in myUrl eine wunderschöne Url-Instanz habe. Wenn ich hingegen eine Try-Klasse oder Fehlermeldungen durch Rückgabewerte oder CallByReference-Parameter verwende, was habe ich dann in myUrl? Vielleicht ne Url, vielleicht aber auch nicht.
Ein Null-Objekt setzt man auch nicht ein, um eine Exception-Behandlung zu ersetzen, sondern, da wo es passt, um den Code einfacher zu halten.

Denn ständig zu prüfen, ob es das Objekt gibt oder nicht um, wenn ja, es dann zu benutzen ist dann etwas umständlich.

Vor allem, wenn dann dieses Objekt auch noch von aussen angesprochen werden soll.
Delphi-Quellcode:
ILogger = interface
  procedure Log( const Text : string );
end;

TFoo = class
private
  FLogger : ILogger;
  function GetLogger : ILogger;
  procedure SetLogger( const Value : ILogger );
public
  property Logger : ILogger read Getlogger write SetLogger;

  procedure Bar;
end;

implementation

type
  TNullLogger = class( TInterfacedObject, ILogger )
    procedure Log( const Text : string );
  end;

procedure TNullLogger.Log( const Text : string );
begin
  // do nothing
end;

procedure TFoo.SetLogger( const Value : ILogger );
begin
  FLogger := Value;
end;

function TFoo.GetLogger : Ilogger;
begin
  if not Assigned( Flogger ) then
    FLogger := TNullLogger.Create;
  Result := Flogger;
end;

procedure TFoo.Bar;
begin
  Logger.Log( 'Bar from TFoo Start' );
  Logger.Log( 'Bar from TFoo Step 1' );
  Logger.Log( 'Bar from TFoo Step 2' );
  Logger.Log( 'Bar from TFoo Step 3' );
  Logger.Log( 'Bar from TFoo Stop' );
end;

end.
Als Logger kann ich jetzt also irgendwas dort unterjubeln, allerdings kann ich zum Ausschalten des Loggens einfach ein nil übergeben, und trotzdem knallt es nicht, es wird aber auch nichts geloggt.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von Meflin
Meflin

Registriert seit: 21. Aug 2003
4.856 Beiträge
 
#26

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 10. Dez 2013, 23:59
was würde denn passieren, wenn ich im Fehlerfall versuche, aufs Success-Objekt zuzugreifen? Krieg ich dann wieder ein Try-Objekt mit Failure? Oder null?
Das hast du falsch verstanden. Das ist so garnicht möglich. Du hast als Rückgabe z.B. ein Try[Int]. Dann ist das entweder ein Failure oder ein Success Objekt. Die konkrete Weiterverwendung ist dann sehr stark abhängig vom spezifischen Anwendungsfall. Aber du kannst mit dem Objekt erstmal weiterarbeiten, ohne zu wissen, was von beiden es ist. Also z.B.
Code:
maybeInt.map(x => x * 2)
Die Überprüfung, ob die ganze Geschichte erfolgreich war, musst du genau ein mal machen, nämlich zum Schluss, genau dann, wenn du das Endergebnis brauchst. Da man mehrere Trys auf diese Weise problemlos verketten kann, sparst du dir da SEHR VIEL Fehlerbehandlungscode.

Zitat:
(Leider) lässt sich nicht alles aus Funktionalen Sprachen auf objektorientierte oder prozedurale Sprachen mappen. Vor allem wenn die Idee erst schon aus diesen Konzepten kommt und ins Funktionale übertragen wurde.
Ist richtig, aber dieser Fall hat nicht sonderlich viel mit funktionaler Programmierung zu tun (außer der Verwendung von Lambdas, die immer nützlich sind).

Zitat:
Da denkst du einfach nur das Falsche, wenn du an Exceptions denkst. Die haben in ihrer Definition gleich viel mit Interrupts zu tun wie eine Applikation im Lambda-Kalkül mit nem call der CPU.
Ist mir schon klar, dass das nichts mit Interrupts zu tun hat. Was ich meinte war das Konzept "ich breche einfach mal mitten drin komplett ab, egal was ich gerade mache, und springe zu einer völlig anderen Codestelle", was beide durchaus gemeinsam haben.

Das spricht doch eigentlich gegen eine Try-Klasse und für Exceptions
Das spricht absolut gegen Exceptions. Nehmen wir doch mal als Beispiel Division durch 0, was prinzipiell ja ein valider Anwendungsfall für Exceptions ist. Kann ich aber auch mit einem Nullobjekt lösen (Pseudocode):
Code:
interface IComputation {
  function currentValue: Float;
  function multiplyBy(other: Float): IComputation;
  function divideBy(other: Float): IComputation;
}

class Computation extends IComputation {
 
  function divideBy(other: Float): IComputation {
    if (other = 0) return new NullComputation();
    return new Computation(this.currentValue / other);
  }
  ...

}

class NullComputation extends IComputation {
  function currentValue: Float { return Float.NaN }
  function divideBy(other: Float): IComputation { return this; }
  ...
}

new Computation(5).divideBy(3).divideBy(0).divideBy(5).currentValue => NaN
Leo S.

Geändert von Meflin (11. Dez 2013 um 00:01 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
9.288 Beiträge
 
Delphi 11 Alexandria
 
#27

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 11. Dez 2013, 06:24
Das spricht absolut gegen Exceptions. Nehmen wir doch mal als Beispiel Division durch 0, was prinzipiell ja ein valider Anwendungsfall für Exceptions ist. Kann ich aber auch mit einem Nullobjekt lösen (Pseudocode):
Code:
new Computation(5).divideBy(3).divideBy(0).divideBy(5).currentValue => NaN
In dem Beispiel fehlt noch die Behandlung welche Division fehlgeschlagen ist. Wie das da schön geht, erschließt sich mir nicht.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#28

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 11. Dez 2013, 07:51
In dem Beispiel fehlt noch die Behandlung welche Division fehlgeschlagen ist. Wie das da schön geht, erschließt sich mir nicht.
Indem in der Division-Methode ein Logging eingebaut wird. Viel hilft es zwar nicht, denn man kann ja nur loggen: 'Bei der Division von 1.2345/0' ist ein Fehler aufgetreten.

Bei Delphi ist es ja auch nicht soo einfach, den Grund einer Fehlrechnung zu erkennen:

Delphi-Quellcode:
Try
  A:=B/C/D/E/F;
Except
  On EDivideByZero do
    // Soll ich hier C,D,E,F prüfen? Blödsinn
    // Also, was tun?
...
Manchmal ist ein Null-Objekt sinnvoll, manchmal nicht. Ich hatte neulich den Fall, das eine Bitmap skaliert werden sollte, also:
Function ScaleBmp (aBitmap : TBitmap; Width : Integer) : TBitmap; Was soll zurückkommen, wenn aBitmap=null? Fail-Fast sagt: Exception! Ich habe gesagt: Na ja... entweder eine leere Bitmap (h=b=0)oder Nil. Wenn ich letzteres verwende, muss ich aber mein gesamtes Framework auf den Sonderfall 'nil' umstellen, ginge, wäre aber blöd.

Wenn ich aber eine leere Bitmap nehme, kann ich transparent mit allen weiteren Methoden arbeiten, ohne auf Nil prüfen zu müssen, was den Code doch etwas unleserlich machen würde. Ich kann eine leere Bitmap skalieren (kommt eh ne leere Bmp raus), filtern, weichzeichnen, Kantenerkennung betreiben, speichern, laden, usw. usw.

Wenn ich einen Rand um eine leere Bmp zeichne, dann entsteht allerdings (je nachdem, ob ich das will) eine nichtleere Bmp oder wieder eine leere Bmp.

Noch ein Wort zu Exceptions. Wir verwenden Exceptions auch zur Validierung:
Delphi-Quellcode:
Procedure TStorage.Store (theObject : TSomeStuff);
Begin
  try
    theObject.Validate();
    Persist(theObject);
  Except
    On E:Exception Do HandleError(E);
  End
End;

Procedure TStorage.HandleError(E:Exception);
Begin
  If E is EValidationException then Raise;

  If E is EPersitingException then begin
    Log('Probleme beim Speichern', E);
    Raise ECannotStoreException.Create('Speicherprobleme');
  end;
  
  if E is Exception then begin
    Log('Programmierfehler', E);
    Raise ECannotStoreException.Create('Programmierfehler');
  end;
end;
Alle Public-Methoden der TStorage-Klasse haben einen Try-Except-Wrapper, der HandleError aufruft. Alle Exceptions, mit Ausnahme der EValidationException, werden gekapselt.

Der Aufrufer muss dann nur die beiden Exceptions abfangen.

Bei einer Validation Exception weiß er dann, das er ne Meldung anzeigen kann und den Anwender die Chance gibt, seine Daten zu ändern.

Ansonsten kann nur eine ECannotStoreException auftreten. Die kann er auch auswerten und z.B. den Vorgang beenden, denn diese Exception bedeutet, das es (derzeit) nicht funktioniert. Konkret müsste man natürlich die genaue Fehlerursache ermitteln (indem der Persister z.B. geeignete Informationen bereitstellt).

Auf jeden Fall sieht der Validator immer gleich aus:
Delphi-Quellcode:
Procedure TSomeStuff.Validate;
Begin
  If SomeData<23 then Raise EValidationException.Create('SomeData too small');
...
Man kann hier auch mit Rückgabewerten arbeiten, aber wenn der Validator wieder andere Validatoren aufruft, wird das wieder nervig. Mit Exceptions bleibt der Code immer einfach zu lesen.
  Mit Zitat antworten Zitat
Benutzerbild von Meflin
Meflin

Registriert seit: 21. Aug 2003
4.856 Beiträge
 
#29

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 11. Dez 2013, 08:20
In dem Beispiel fehlt noch die Behandlung welche Division fehlgeschlagen ist. Wie das da schön geht, erschließt sich mir nicht.
Es hindert dich ja auch niemand daran, das Nullobjekt um beliebige Fehlerinformationen zu erweitern. Dann könntest du in diesem Fall, wenn du das denn wölltest, sogar konkret speichern, dass der Fehler genau bei der x-ten Berechnung aufgetreten ist. Und dann hast du schonmal deutlich mehr Infos, als mit dem äquivalenten Exception-Code (wie von Furtbichler gezeigt).
Leo S.
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.604 Beiträge
 
#30

AW: Best Practice: Wann verwendet ihr Exceptions in Funktionen?

  Alt 11. Dez 2013, 09:09
Manchmal ist ein Null-Objekt sinnvoll, manchmal nicht. Ich hatte neulich den Fall, das eine Bitmap skaliert werden sollte, also:
Function ScaleBmp (aBitmap : TBitmap; Width : Integer) : TBitmap; Was soll zurückkommen, wenn aBitmap=null? Fail-Fast sagt: Exception! Ich habe gesagt: Na ja... entweder eine leere Bitmap (h=b=0)oder Nil. Wenn ich letzteres verwende, muss ich aber mein gesamtes Framework auf den Sonderfall 'nil' umstellen, ginge, wäre aber blöd.
Korrekt. Ich als .NET'ler überprüfe auch üblicherweise erstmal meine Argumente. In dem Fall würde ich auch gleich eine ArgumentNullException werfen. Wenn die Funktion nur in einem bestimmten Bereich skalieren kann, und width ausserhalb der validen Werte liegt, gibts auch gleiche ne ArgumentOutOfRangeException (oder eine mehr generische ArgumentException mit entsprechendem Fehlertext).

Sowas (= konkret eine Fehlbedienung) sollte maximal beim Entwickeln passieren und nicht im normalen Programmablauf. Und wenn doch, ist woanders was schief gelaufen (Ausnahmesituation) Da sind Exceptions natürlich das Mittel der Wahl.
Sebastian Gingter
Phoenix - 不死鳥
Mein Blog: http://gingter.org
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:23 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz