Can exceptions be resumeable?

[=?ISO-8859-1?Q?Thomas_Gagn=E9?=]

Is there a way of continuing processing from the point (or just after) a
throw? Rather than retrying everything inside try {} I'm wondering if
once inside the catch {} I can fix whatever the problem was (or ignore
it) and continue precisely from where I left off. In this specific case
putting the try{} inside a while {} isn't practical.

 

[Bent C Dalager]

Is there a way of continuing processing from the point (or just after) a
throw? Rather than retrying everything inside try {} I'm wondering if
once inside the catch {} I can fix whatever the problem was (or ignore
it) and continue precisely from where I left off.

Not as such. I assume you are looking for something like

try
{
maybeThrows();
throwsNot();
maybeThrows2();
alsoThrowsNot();
}
catch (Exception ex)
{
if (canWeLiveWith(ex)) resume;
}

in which case you'd have to do something like

try
{
maybeThrows();
}
catch (Exception ex)
{
if (!canWeLiveWith(ex)) return;
}

throwsNot();

try
{
maybeThrows2();
}
catch (Exception ex)
{
if (!canWeLiveWith(ex)) return;
}

alsoThrowsNot();


Cheers
Bent D

 

[Adam Maass]

Is there a way of continuing processing from the point (or just after) a
throw? Rather than retrying everything inside try {} I'm wondering if
once inside the catch {} I can fix whatever the problem was (or ignore
it) and continue precisely from where I left off. In this specific case
putting the try{} inside a while {} isn't practical.

--

No, not really. Though I might try something like this:

try{
doSomethingInteresting();
} catch (SomethingInterestingException e) {
fixit();
doSomethingInteresting();
}


-- Adam Maass

 

[pete kirkham]

Is there a way of continuing processing from the point (or just after) a
throw? Rather than retrying everything inside try {} I'm wondering if
once inside the catch {} I can fix whatever the problem was (or ignore
it) and continue precisely from where I left off. In this specific case
putting the try{} inside a while {} isn't practical.

No, but for an interpreter I've just coded something like:

class Variable {
getValue () {
if (!bound) {
new UnboundVariable(this).error();
}
return the value of the variable;
}
}

class UnboundVariable extends RecoverableError {
//which in turn extends RuntimeException
final Variable variable;

error () { // abstract method in superclass
if there's a debugger {
ask user to enter a value for variable
set the variable value
} else {
throw this;
}
}
}

Which might be a way of working it, if the code that's throwing the
exception is part of your project, and the exceptions have common ways
of handling their causes.

But most Java libary functions are not based on this idiom.


Pete