X-Received: by 10.99.217.21 with SMTP id r21mr8424123pgg.144.1485880018587; Tue, 31 Jan 2017 08:26:58 -0800 (PST)
X-Received: by 10.157.34.34 with SMTP id o31mr1938127ota.13.1485880018539; Tue, 31 Jan 2017 08:26:58 -0800 (PST)
Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.glorb.com!r185no1622342ita.0!news-out.google.com!15ni9877itm.0!nntp.google.com!r185no1622335ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: de.comp.lang.java
Date: Tue, 31 Jan 2017 08:26:58 -0800 (PST)
In-Reply-To: <o6pnoh$udl$1@newsreader4.netcologne.de>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=77.185.235.95; posting-account=VmIUsgkAAABUMV5-gaSlvHjNMDcqojz2
NNTP-Posting-Host: 77.185.235.95
References: <da729f39-9df8-4d89-9689-c2c19949a437@googlegroups.com> <c689a210-367e-4c9c-97f8-6ec9e316ff9c@googlegroups.com> <o6pnoh$udl$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <85660ce3-c2bc-4ba3-8e83-e2d9566b9cd2@googlegroups.com>
Subject: Re: Algorithmus zum Finden des speziellsten Super-Typ eines multi-catch
From: =?UTF-8?Q?Heiner_K=C3=BCcker?= <mail@heinerkuecker.de>
Injection-Date: Tue, 31 Jan 2017 16:26:58 +0000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Xref: csiph.com de.comp.lang.java:13094

Am Dienstag, 31. Januar 2017 11:09:22 UTC+1 schrieb Patrick Roemer:
> Responding to Heiner K=C3=BCcker:
> > String und Integer als Typ-Argumente sind eigentlich disjoint.
> >=20
> > Demzufolge geh=C3=B6rt die Methode m mit jeweiligem Typ nicht zur Typ-V=
ereinigungsmenge.
> >=20
> > Hier haben die Compiler-Bauer scheinabr ein Auge zugedr=C3=BCckt
> > und es wie Raw-Typen behandelt.
>=20
> Nicht ganz so schlimm, bzw. je nach Sichtweise noch schlimmer. ;) Da
> wird schon irgendwie der "speziellste gemeinsame Typ" inferiert, ganz
> wie von Dir gew=C3=BCnscht - aber dabei wird nonchalant so getan, als sei=
en
> Generics, =C3=A4h, sagen wir: punktuell covariant. F=C3=BCr Integer/Strin=
g
> w=C3=A4re das (vereinfacht) MyExceptionInterface<? extends Object>, f=C3=
=BCr
> Integer/Long hingegen MyExceptionInterface<? extends Number>. Was
> nat=C3=BCrlich auch wieder Murks ist.
>=20
> Wie auch immer, im Integer/Long-Fall ginge z.B. folgendes:
>=20
> MyExceptionInterface<? extends Number> nei =3D e;
> Number n =3D e.m();
>=20
> Keine Ahnung, ob sich das konsistent aus der JLS begr=C3=BCnden l=C3=A4ss=
t. Falls
> ja, liest sich das sicher lustig. :)
>=20
> Viele Gr=C3=BC=C3=9Fe,
> Patrick

Ich habe es mit Long und Integer ausprobiert:

public class TryCatch
{

	static interface MyExceptionInterface<T>
	{
		// gemeinsame Methode beider union-Exceptions
		T m(T t);
	}

	static class MyException1
	extends Exception
	implements MyExceptionInterface<Long>
	{

		public Long m(
				Long str )
		{
			return "";
		}
	=09
	}

	static class MyException2
	extends Exception
	implements MyExceptionInterface<Integer>
	{

		public Integer m(
				Integer  i)
		{
			return 0;
		}
	=09
	}
=09
	void m()
	throws MyException1 , MyException2
	{
		try
		{
			m();
		}
		catch ( MyException1 | MyException2 e )
		{
			// Aufruf gemeinsame Methode
			System.err.println( e.m( null ) );
			Number o =3D e.m( null );
			// Parameter-=C3=9Cbergabe nicht kompilierbar, entspricht der punktuell-=
kovariant-Annnahme: Number o =3D e.m( Long.valueOf( 0 ) );
			// Parameter-=C3=9Cbergabe nicht kompilierbar, entspricht der punktuell-=
kovariant-Annnahme: Number o =3D e.m( Integer.valueOf( 0 ) );
		}
	}
=09
}

Genau wie von Dir angegenommen kann der R=C3=BCckgabewert der Methode einem=
 Number zugewiesen werden, aber Number ist nicht zuweisbar, also kovariant.

Keine Ahnung, wie Du darauf gekommen bist, schon ziemlich genial.

Danke