java - throws x extends Exception method signature -


reading javadoc of optional, bumped in weird method signature; never saw in life:

public <x extends throwable> t orelsethrow(supplier<? extends x> exceptionsupplier)                                 throws x extends throwable 

at first glance, wondered how generic exception <x extends throwable> possible, since can't (here, , here). on second thought, starts make sense, here bind supplier... supplier knows type should be, before generics.

but second line hit me:

  • throws x complete generic exception type.

and then:

  • x extends throwable, in world this mean?
    • x bound in method signature.
  • will means, solve generic exception restriction?
  • why not throws throwable, rest erased type erasure?

and one, not directly related question:

  • will method required caught catch(throwable t), or provided supplier's type; since can't checked @ runtime?

treat other generic code you've read.

here's formal signature see in java 8's source code:

public <x extends throwable> t orelsethrow(supplier<? extends x> exceptionsupplier) throws x 
  • x has upper bound of throwable. important later on.
  • we return type t bound optional's t
  • we expect supplier has wildcard upper bound of x
  • we throw x (which valid, since x has upper bound of throwable). specified in jls 8.4.6; long x seen subtype of throwable, declaration valid , legal here.

there open bug javadoc being misleading. in case, it's best trust source code opposed documentation until bug declared fixed.

as why we're using throws x instead of throws throwable: x guaranteed bound throwable in uppermost bounds. if want more specific throwable (runtime, checked, or error), merely throwing throwable wouldn't give flexibility.

to last question:

will method required caught in catch(throwable t) clause?

something down chain has handle exception, try...catch block or jvm itself. ideally, 1 want create supplier bound exception best conveyed needs. don't have (and should not) create catch(throwable t) case; if supplier type bound specific exception need handle, it's best use catch later in chain.


Comments

Popular posts from this blog

javascript - gulp-nodemon - nodejs restart after file change - Error: listen EADDRINUSE events.js:85 -

Fatal Python error: Py_Initialize: unable to load the file system codec. ImportError: No module named 'encodings' -

javascript - oscilloscope of speaker input stops rendering after a few seconds -