Ich versuche eine abstrakte Methode für erbende Klassen zu schreiben, die allerdings verschiedene Exceptions werfen.
* Executes the main process for a service of the type
* ToolboxingService,ConvertService... generates the result which has to be
* written by Service.writeResult()
*
* @param targetExtention
* @param options
* @throws Exception
*
*/
public abstract void process(String targetExtention, Object options) throws Exception;```
Diese Vorgangsweise funktioniert grundsätzlich allerdings würde ich gerne wissen ob es noch andere Möglichkeiten gibt die Methode mit verschiedenen Exceptions zu nutzen.
Das throws java.lang.Exception wird mir auf jeden Fall von unserer Codeanalyse-Software als schlechter Stil bemängelt.
welche Exceptions gibt es denn, nicht wenigstens eine gemeinsame Basisklasse ServiceException oder so?
Exception selber ist unschön, wenn man das fangen will hat man auch NullPointerException usw. dabei,
RuntimeExceptions zu werfen hat Vorteile wie kein throws dranzuschreiben, das Problem in der abstrakten Klasse totzuschweigen,
sofern aber nicht wiederum ServiceException als gemeinsame Basis-RuntimeException vorliegt
im Handling an allgemeiner Stelle auch nicht allzu nützlich aus gleichen Grund,
wenn aber für jeweiligen Aufruf bekannt ist was drankommt, dann ja doch ganz gut
Generics funktioniert lustigerweise auch mit Exceptions
public class Test2
{
public static void main(String[] args)
{
C1 c1 = new C1();
if (false) c1.e();
C2 c2 = new C2();
try
{
c2.e();
}
catch (IOException e1)
{
System.out.println("was: " + e1);
}
C c = c1;
try
{
c.e();
}
catch (Exception e)
{
System.out.println("was: " + e);
}
}
static abstract class C<T extends Exception>
{
abstract void e()
throws T;
}
static class C1
extends C<IllegalArgumentException>
{
void e()
throws IllegalArgumentException
{
throw new IllegalArgumentException();
}
}
static class C2
extends C<IOException>
{
void e()
throws IOException
{
throw new IOException();
}
}
}
class ServiceException<T> extends RuntimeException
geht ist, siehe
macht auch Sinn bei allgemeiner Verarbeitung, Generics-Information ginge verloren
wiederum möglich wäre, dass alle real eine ServiceException werfen (nicht Subklasse),
intern dann weitere Informationen als Attribute enthalten
gibt es ja auch allgemein schom im Exceptionwesen, jede Exception hat intern Throwable-Attribut cause
Damit zwingst du jeden Verwender der Methode sich mit der Fehlerbehandlung dieser Exception auseinanderzusetzen. Kann denn jeder der die Methode verwenden wird die Exception behandeln bzw. einen gültigen Zustand herstellen oder wird die Exception nur stumpf, manuell nach oben weitergeworfen? Des Weiteren, soll die Methode später mal in einem Lambda-Ausdruck enden geht das dann nur noch auf Kosten extremer Hässlichkeit.