.NET has a broken Exception model

  • Thread starter Thread starter cody
  • Start date Start date
You could try this:
try {
return new DateTime(int.Parse(tbYear.Text),
Click to expand...
int.Parse(tbMonth.Text), int.Parse(tbDay.Text));
}
catch (Exception e) {

if ( ((e as FormatException) != null) || ((e as
Click to expand...
ArgumentException) != null) || ((e as OverflowException) != null) ) {
// do stuff here
} else {
throw e;
}
}

This will catch all the exceptions in one place, and rethrow anything you
Click to expand...
didn't want to catch (like OutOfMemoryException, for example).
Also, VB.NET has exception filtering, not unlike how you described below.
Click to expand...


Good idea, but rethrowing will loose the stack trace.
 
Look at the Exception hirarchy, and see what sloppy work microsoft has
done.

I don't look at the model as being broken or sloppy, it's more that it is
immature and incomplete. The problem with trying to categorize exceptions
(and I've thought some about how to do it) is that I think it would be very
difficult, if not impossible, to come up with a single hierarchy that worked
for all the cases. Any such hierarchy would likely lock developers into a
number of version dependencies that would make it difficult to move the
framework forward. For example, is StackOverflow fatal? Perhaps it is in the
current rev, but perhaps not in the next one. Perhaps it is fatal on the
main thread and not on a worker thread. It would be hard to come up with a
hierarchy that was both meaningful and which did not impose an undue burden
on developers.
Click to expand...

I do not agree. a StackOverflow is fatal, it always was and will always be.
Even if not, you certainly don't want to catch it, especially not accidently
whech catch (Exception)
IMO the evolution of tools that can do static analysis to predict exception
types and exception flow will help this. I also believe that there will be
future languages that more directly attack this problem. There are a number
of problems with using exceptions but I find that it is still far superior
to using the other common mechanisms, such as sentinel return values.

One of the fundamental problems with the current implementation in .NET is
that exceptions are very loosely typed (other then it being derived from
System.Exception). I look at exceptions as a side-band channel for moving
data back up the call stack, but there is no API contract or definition,
other then documentation, to define what exception types to expect. Because
of this the runtime cannot enforce consistency and correctness.
Click to expand...

Thats true, you never know for sure which Exceptions will be thrown.
I don't want
a Java style checked-exception because it is too constraining, but what we
have now is too wide open.
Agreed.

IMO this is a difficult problem to solve.
Click to expand...

Indeed. But I tried it:

I would make 3 Categories:

FatalException (unexpected, fatal, cannot recover, indicates serious bugs)
- StackOverflow
- InvalidProgram,
- OutOfMemory
- ExcutionEngine

SystemException (unexpected, nonfatal, normally indicates bugs)
- ArithmeticException
- NullReference
-ArgumentException
-ArgumentNull
-ArgumentOutOfRange
-IndexOutOfBounds
-FormatException

ApplicationException (expected, nonfatal, common, does not necessarily
indicate a bug, they can for example happen on wrong operations by the user)
-IOException
-InvalidOperationException
-SecurityException
-[All other exceptions that are based on hardware/OS failures, missing
hardware/OS-features, wrong versions, security issues, user decisions and so
on]

Alle three should be derived from System.Exception:

Exception
-FatalException
-ApplicationException
-SystemException

Now it is a really good Exception Hirarchy!
 
cody said:
int.Parse(tbMonth.Text), int.Parse(tbDay.Text));
ArgumentException) != null) || ((e as OverflowException) != null) ) {
didn't want to catch (like OutOfMemoryException, for example).
Click to expand...
Thats why you should use throw; I think that doesn't change the stack
trace...you'll have to experiment with it to make sure.
 
Cor Ligthert said:
Hi Brian,

I did not like this statement when I got the first explanations about this
in these newsgroups, because I thought it was an useless addition to the
logical Or in VB.net.

However it is a build in statement like this pseudo

If not a = 1
if not b = 1
if not c = 1

While the logical Or in VB does evaluate all expressions even when one is
false, thinking this over I agree with you that falling down the Catch
statements will be the same. However than it is an addition to use in this
case in VB.net OrElse.

Maybe that is the same behaviour as the C# logical Or || that I do not
know.

So when it is, than tell me because now I am curious about it?
Click to expand...

|| is pretty much equivilent to OrElse. As cody said it performs a
short-circuted comparison. && is also equivilent to VB's AndAlso, & is Ands
and | is Ors I believe. There might be some subtle differences(I'm not a VB
expert) but they should be pretty close, all in all.
 
cody said:
I don't look at the model as being broken or sloppy, it's more that it is
immature and incomplete. The problem with trying to categorize exceptions
(and I've thought some about how to do it) is that I think it would be very
difficult, if not impossible, to come up with a single hierarchy that worked
for all the cases. Any such hierarchy would likely lock developers into a
number of version dependencies that would make it difficult to move the
framework forward. For example, is StackOverflow fatal? Perhaps it is in the
current rev, but perhaps not in the next one. Perhaps it is fatal on the
main thread and not on a worker thread. It would be hard to come up with
a
hierarchy that was both meaningful and which did not impose an undue burden
on developers.
Click to expand...

I do not agree. a StackOverflow is fatal, it always was and will always
be.
Even if not, you certainly don't want to catch it, especially not
accidently
whech catch (Exception)
IMO the evolution of tools that can do static analysis to predict exception
types and exception flow will help this. I also believe that there will
be
future languages that more directly attack this problem. There are a number
of problems with using exceptions but I find that it is still far
superior
to using the other common mechanisms, such as sentinel return values.

One of the fundamental problems with the current implementation in .NET
is
that exceptions are very loosely typed (other then it being derived from
System.Exception). I look at exceptions as a side-band channel for moving
data back up the call stack, but there is no API contract or definition,
other then documentation, to define what exception types to expect. Because
of this the runtime cannot enforce consistency and correctness.
Click to expand...

Thats true, you never know for sure which Exceptions will be thrown.
I don't want
a Java style checked-exception because it is too constraining, but what
we
have now is too wide open.
Agreed.

IMO this is a difficult problem to solve.
Click to expand...

Indeed. But I tried it:

I would make 3 Categories:

FatalException (unexpected, fatal, cannot recover, indicates serious bugs)
- StackOverflow
- InvalidProgram,
- OutOfMemory
- ExcutionEngine

SystemException (unexpected, nonfatal, normally indicates bugs)
- ArithmeticException
- NullReference
-ArgumentException
-ArgumentNull
-ArgumentOutOfRange
-IndexOutOfBounds
-FormatException

ApplicationException (expected, nonfatal, common, does not necessarily
indicate a bug, they can for example happen on wrong operations by the
user)
-IOException
-InvalidOperationException
-SecurityException
-[All other exceptions that are based on hardware/OS failures, missing
hardware/OS-features, wrong versions, security issues, user decisions and
so
on]

Alle three should be derived from System.Exception:

Exception
-FatalException
-ApplicationException
-SystemException

Now it is a really good Exception Hirarchy!
Click to expand...

Maybe it is, maybe. Unfortunatly, until you add every existing exception and
make sure there are no conflicts you can't safely define a root hiearchy.
There may be some which could exist in both SystemException and
APplicationException for example, or some which don't fit any of these.
While I agree that your basic layout is pretty good, I'm not sure it covers
everything.
 
I do not agree. a StackOverflow is fatal, it always was and will always be.
Even if not, you certainly don't want to catch it, especially not accidently
whech catch (Exception)
Click to expand...

I disagree. Execution engines that run user-defined code (e.g. a plug-in
architecture) should account for buggy code. A good plugin architecture sets
up both a security sandbox and an execution sandbox so that a buggy plugin
does not compromise the entire system.

I would make 3 Categories:

FatalException (unexpected, fatal, cannot recover, indicates serious bugs)
- StackOverflow
- InvalidProgram,
- OutOfMemory
- ExcutionEngine
Click to expand...

The only one I would agree with all the time is the ExecutionEngine, and
only because this represents the case where the CLR itself cannot continue.

SystemException (unexpected, nonfatal, normally indicates bugs)
- ArithmeticException
- NullReference
-ArgumentException
-ArgumentNull
-ArgumentOutOfRange
-IndexOutOfBounds
-FormatException

ApplicationException (expected, nonfatal, common, does not necessarily
indicate a bug, they can for example happen on wrong operations by the user)
-IOException
-InvalidOperationException
-SecurityException
-[All other exceptions that are based on hardware/OS failures, missing
hardware/OS-features, wrong versions, security issues, user decisions and so
on]

Alle three should be derived from System.Exception:

Exception
-FatalException
-ApplicationException
-SystemException

Now it is a really good Exception Hirarchy!
Click to expand...
I don't think you will get wide spread agreement; that's probably why MSFT
has not yet done it.
 
William said:
Tom:

I think his whole point is that System.Exception is a lame approach
but not using it requires quite a bit of code for this situation.
Take Cody's example directly and say that based on those exceptions,
he returns lets say a return code of 0. Now, if something more
severe happens or is outside of the bounds there, say the classic
OutOfMemory exception, System.Exception is going to catch it and
return a 0. There would be no differentiation between the two. Do
this in a class library that you distribute and you could really
obscure some ugly bugs.
Click to expand...

Reread what I said. I said SystemException, not System.Exception. There is
a distinct difference. All exceptions inherit from System.Exception.
System.SystemException is the base for non-fatal or recoverable exceptions.
The problem comes in when what one person considers recoverable someone else
may consider fatal.
Personally in this situation I trap all my exceptions specifically
and don't really have a problem b/c I seldom do the same things for
different exceptions (actually, I never do unless it's an oversight)
so it's not really an issue to me, but if I wanted to trap those four
things and respond the same way to each of them like he mentions,
then it would cause you to write some extraneous code. But catching
System.Exception in an instance like this seems to be the worst of
all worlds (I mean no offense by this, just MHO). You can't possibly
know/anticipate and respond specifically to every possible exception
under the sun and assuming one wanted to make the argument they could
(mathematically it's possible), you'd defintiely write a lot of code
that you didn't know.
Click to expand...

No offense taken as you didn't read my original message correctly.

It really depends on what the requirement is. If you only care about four
specific exceptions then you have to filter in some way, either with
distinct catches or a more generic catch and then throw if the exception
isn't what you wanted. Like just about any problem, this one has multiple
solutions, all with their own merit.
--
Tom Porterfield
MS-MVP MCE
http://support.telop.org

Please post all follow-ups to the newsgroup only.
 
(inline)

Tom Porterfield said:
Reread what I said. I said SystemException, not System.Exception. There is
a distinct difference. All exceptions inherit from System.Exception.
System.SystemException is the base for non-fatal or recoverable exceptions.
The problem comes in when what one person considers recoverable someone else
may consider fatal.
Click to expand...

It's probably best, to avoid a neverending argument, to distinguish between
two sorts of fatal vs non-fatal:

1) Fatal exceptions as defined by the framework. They are
OutOfMemoryException, ExecutionEngineException, and StackOverflowException.
You simply can't catch them, except possibly within the unhandled exception
handler.

2) Fatal within the context of a block of code. So in the current example,
FormatException, ArgumentException and OverflowException are being
considered as non-fatal (ie they aren't going to be allowed out of this
stack frame). All other exceptions are outside the scope of that block of
code, and will unwind until some other block of code considers itself
capable of dealing with them.

I tend to use "fatal" for case (1) but I suppose you could use it for case
(2).


Personally, in the case of this thread, I'd say the problem is that there is
no Int32.TryParse or DateTime.TryParse (cf Double.TryParse) in the
framework, as opposed to a shortcoming of the exception system.

Stu
 
I think his whole point is that System.Exception is a lame approach
Reread what I said. I said SystemException, not System.Exception. There is
a distinct difference. All exceptions inherit from System.Exception.
System.SystemException is the base for non-fatal or recoverable exceptions.
The problem comes in when what one person considers recoverable someone else
may consider fatal.
Click to expand...

You are wrong. Look at the Exception hirarchy. There is no base-class for
non-fatal exceptions in .NET.
These Exceptions derive from System.SystemException:

System.ExecutionEngineException
System.ArithmeticException
System.InvalidProgramException
System.OutOfMemoryException
System.StackOverflowException

So catching SystemException catches them also, which is certainly not what
we want.
 
I do not agree. a StackOverflow is fatal, it always was and will always
be.
Even if not, you certainly don't want to catch it, especially not accidently
whech catch (Exception)
Click to expand...

I disagree. Execution engines that run user-defined code (e.g. a plug-in
architecture) should account for buggy code. A good plugin architecture sets
up both a security sandbox and an execution sandbox so that a buggy plugin
does not compromise the entire system.

I would make 3 Categories:

FatalException (unexpected, fatal, cannot recover, indicates serious bugs)
- StackOverflow
- InvalidProgram,
- OutOfMemory
- ExcutionEngine
Click to expand...

The only one I would agree with all the time is the ExecutionEngine, and
only because this represents the case where the CLR itself cannot continue.
SystemException (unexpected, nonfatal, normally indicates bugs)
- ArithmeticException
- NullReference
-ArgumentException
-ArgumentNull
-ArgumentOutOfRange
-IndexOutOfBounds
-FormatException

ApplicationException (expected, nonfatal, common, does not necessarily
indicate a bug, they can for example happen on wrong operations by the user)
-IOException
-InvalidOperationException
-SecurityException
-[All other exceptions that are based on hardware/OS failures, missing
hardware/OS-features, wrong versions, security issues, user decisions
Click to expand...
and
so
on]

Alle three should be derived from System.Exception:

Exception
-FatalException
-ApplicationException
-SystemException

Now it is a really good Exception Hirarchy!
Click to expand...
I don't think you will get wide spread agreement; that's probably why MSFT
has not yet done it.
Click to expand...


Maybe you cannot classify Exceptions in Fatal/Nonfatal that easily. Forget
about that.

But You will Agree with me that you very rarely want to catch a
StackOverflowException.
An ArgumentException is more common to catch and an IOException belongs to
an absolutely comon thing to catch.

The Point is to classify Exceptions in expected Exceptions and unexpected
Exceptions and very rare Exceptions that never normally should not occur.
so that you safely can catch an ApplicationException (from my
classification) knowing that you only catch exceptions commonly thrown by
methods.

This way, you have a contract: Methods should never throw Exceptions but
those derived from ApplicationException. If another exception occures
(ArithmeticException, NullReference) or similar, you know something is
wrong.
 
Good idea, but rethrowing will loose the stack trace.
Thats why you should use throw; I think that doesn't change the stack
trace...you'll have to experiment with it to make sure.
Click to expand...

Theoretically. But I've read a longer timer ago that this is not the full
truth.
The difference between rethrow and applying ExceptionFilters was the main
argument for the usage of ExceptionFilters but I cannot remember what it
was.
In VS if you are in debug mode, a rethrown Exception won't lead you to the
point where the original Exception was thrown, for example.
 
OK, maybe fatal or non-fatal is a bit fuzzy. But what about expected and
unexpected? Stackoverflow,Arithmetic, ExecutionEngine-Exceptions are
normally not Expected while IOException is commonly caught.

So I would at least distinguish between expected, unexpected and rare
Exceptions, see my other posts for details.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
Because what is fatal for one is not fatal for another....


cody said:
trivialize
it, inconvenient
but built
with


The problem is that you never now which kind of exception a method might
throw and you often end up with catching System.Exception because it is
often the safest and simplest way. I cannot understand why the exception
hirarchy isn't designed this way that it separates fatal from nonfatal
exceptions, instead you have all exception cluttered together in a way that
is beyond any comprehension:
Click to expand...
http://msdn.microsoft.com/library/d...f/html/frlrfsystemexceptionclasshierarchy.asp
--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
My apologies, I thought you were referring to application exceptionss
but
seeing the code I see your point.

And? No answers? Hints? Iam starting to hate .NET for this!

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
If I understand you correctly, the functionality is already there.
You
can
inherit from ApplicationException which is thrown when
Click to expand...
Click to expand...
non-fatalhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
thrown
Click to expand...
Click to expand...
 
IMO this is a difficult problem to solve.
Indeed. But I tried it:

I would make 3 Categories:

FatalException (unexpected, fatal, cannot recover, indicates serious bugs)
- StackOverflow
- InvalidProgram,
- OutOfMemory
- ExcutionEngine

SystemException (unexpected, nonfatal, normally indicates bugs)
- ArithmeticException
- NullReference
-ArgumentException
-ArgumentNull
-ArgumentOutOfRange
-IndexOutOfBounds
-FormatException

ApplicationException (expected, nonfatal, common, does not necessarily
indicate a bug, they can for example happen on wrong operations by the
user)
-IOException
-InvalidOperationException
-SecurityException
-[All other exceptions that are based on hardware/OS failures, missing
hardware/OS-features, wrong versions, security issues, user decisions and
so
on]

Alle three should be derived from System.Exception:

Exception
-FatalException
-ApplicationException
-SystemException

Now it is a really good Exception Hirarchy!
Click to expand...

Maybe it is, maybe. Unfortunatly, until you add every existing exception and
make sure there are no conflicts you can't safely define a root hiearchy.
There may be some which could exist in both SystemException and
ApplicationException for example, or some which don't fit any of these.
Click to expand...

I cannot imagine one. SystemExceptions should be thrown by the CLR while
ApplicationExceptions should be thrown by applictions and libraries.
While I agree that your basic layout is pretty good, I'm not sure it covers
everything.
Click to expand...

Thank you. While I have something like a layout Iam still trying to figure
out wheather the .NET Exception hirarchy has a structure at all..
 
You could try this:
Thats why you should use throw; I think that doesn't change the stack
trace...you'll have to experiment with it to make sure.
Click to expand...


Now I know what the problem with rethrowing was: If I recall correctly,
you'll lose the state of the local variables.
 
It's probably best, to avoid a neverending argument, to distinguish between
two sorts of fatal vs non-fatal:

1) Fatal exceptions as defined by the framework. They are
OutOfMemoryException, ExecutionEngineException, and StackOverflowException.
You simply can't catch them, except possibly within the unhandled exception
handler.
Click to expand...

Even these can change, and they probably will. About the only one I can
think of that would always be fatal is ExecutionEngineException as that
indicates that the runtime itself is corrupt. But even these distinctions
are not all that useful because there is high liklihood that if the runtime
itself detected its own internal corruption, as it likely in one of these
three exceptions, it would probably halt its normal exception propagation
and simply terminate the app, so you really couldn't catch it anyway.
Personally, in the case of this thread, I'd say the problem is that there is
no Int32.TryParse or DateTime.TryParse (cf Double.TryParse) in the
framework, as opposed to a shortcoming of the exception system.

Stu
Click to expand...

there is a double.TryParse, and one of its arguments let's you specify its
type (int, float, etc).
 
Maybe you cannot classify Exceptions in Fatal/Nonfatal that easily. Forget
about that.

But You will Agree with me that you very rarely want to catch a
StackOverflowException.
An ArgumentException is more common to catch and an IOException belongs to
an absolutely comon thing to catch.
Click to expand...

Well, as I said earlier, I can forsee a runtime that provides a more robust
environment for running arbitrary code in sandboxes. In this case when such
an exception occurs I might want to terminate an appdomain, but I would not
want exception to be fatal to the entire app unless that was a policy
decision made by the host.

The Point is to classify Exceptions in expected Exceptions and unexpected
Exceptions and very rare Exceptions that never normally should not occur.
so that you safely can catch an ApplicationException (from my
classification) knowing that you only catch exceptions commonly thrown by
methods.

This way, you have a contract: Methods should never throw Exceptions but
those derived from ApplicationException. If another exception occures
(ArithmeticException, NullReference) or similar, you know something is
wrong.

--
Click to expand...

I agree with your intent, but the problem is that the current mechanism
really doesn't support, at least not in a generically useful manner, the
type of categorization you want to do. Given the current architecture and
implementation of exceptions it is most useful when the exception hierarchy
is wide but not very deep. As soon as you try to deepen the hierarchy, which
is what trying to classify exceptions into different categories would do,
you run into all sorts of practical problems that I don't believe can be
overcome. You may come up with perfect categories, but it's only perfect for
your usage.

Even though exception objects are fully object oriented by themselves, and
you can create a complex hierarchy based on them, in practice it does not
appear very useful to create such a hierarchy.

I look at it this way...methods identifies its arguments, both input and
output, and the return value, as types, as specified by the method
signature - this constitutes an API contract. One of the problems with
exceptions is that there is no means of specifying an exception contract -
it is fully untyped, even to the point that there really is no guarantee
that only exceptions that derive from System.Exception will be thrown (code
written in IL can throw integers). This makes it backwardly compatible with
Win32, but it imposes limitations as well. You can constrain the code so
that it only deals with a subset of these, in this case limiting the code to
be CLS-compliant so that it only catches types derived from
System.Exception, but the runtime itself is not so constrained.

The fact that the runtime does not enforce a type system on exceptions, and
because there is no exception contract mechanism that can be enforced by the
runtime, means that the only standards that can be applied are those applied
via coding discipline. One of the truths in computing is that any system
that relies on programmer hygiene is doomed - it must be enforced by a
runtime mechanism for it to succeed.

IMO, a better system would involve high-level abstractions so that exception
contracts, or perhaps more generically, an error contract, could be
specified and to have the CLR participate in this. Perhaps I'm the only one
who sees value in such a system, but in the meantime I'll try to make the
best of what I've got to work with and make do until something better comes
along.
 
cody said:
Theoretically. But I've read a longer timer ago that this is not the full
truth.
The difference between rethrow and applying ExceptionFilters was the main
argument for the usage of ExceptionFilters but I cannot remember what it
was.
In VS if you are in debug mode, a rethrown Exception won't lead you to the
point where the original Exception was thrown, for example.
Click to expand...

The difference is really quite simple. The statement

throw e;

will reset the stack trace in exception object "e" so that the stack trace
begins on the same line as the throw statement. The statement:

throw;

will rethrow the original exception object without resetting the stack
trace.

So if you catch an exception, examine and decide you don't really want to
handle it and have nothing of value to add, then simply use
throw;

If you want to erase from the stack trace the original line that generated
the exception (in essence, hide information) then use:

throw e;

If you want to add context (this is usually what I do), then use something
like this:

throw new Exception("What I was doing.",ex);

This preserves the original exception as the inner exception in the
exception object. The difference is that I did not preserve the exception
type, but I could have done that as well had I wanted to.
 
Dave said:
Well, as I said earlier, I can forsee a runtime that provides a more robust
environment for running arbitrary code in sandboxes. In this case when such
an exception occurs I might want to terminate an appdomain, but I would not
want exception to be fatal to the entire app unless that was a policy
decision made by the host.



I agree with your intent, but the problem is that the current mechanism
really doesn't support, at least not in a generically useful manner, the
type of categorization you want to do. Given the current architecture and
implementation of exceptions it is most useful when the exception hierarchy
is wide but not very deep. As soon as you try to deepen the hierarchy, which
is what trying to classify exceptions into different categories would do,
you run into all sorts of practical problems that I don't believe can be
overcome. You may come up with perfect categories, but it's only perfect for
your usage.

Even though exception objects are fully object oriented by themselves, and
you can create a complex hierarchy based on them, in practice it does not
appear very useful to create such a hierarchy.

I look at it this way...methods identifies its arguments, both input and
output, and the return value, as types, as specified by the method
signature - this constitutes an API contract. One of the problems with
exceptions is that there is no means of specifying an exception contract -
it is fully untyped, even to the point that there really is no guarantee
that only exceptions that derive from System.Exception will be thrown (code
written in IL can throw integers). This makes it backwardly compatible with
Win32, but it imposes limitations as well. You can constrain the code so
that it only deals with a subset of these, in this case limiting the code to
be CLS-compliant so that it only catches types derived from
System.Exception, but the runtime itself is not so constrained.

The fact that the runtime does not enforce a type system on exceptions, and
because there is no exception contract mechanism that can be enforced by the
runtime, means that the only standards that can be applied are those applied
via coding discipline. One of the truths in computing is that any system
that relies on programmer hygiene is doomed - it must be enforced by a
runtime mechanism for it to succeed.

IMO, a better system would involve high-level abstractions so that exception
contracts, or perhaps more generically, an error contract, could be
specified and to have the CLR participate in this. Perhaps I'm the only one
who sees value in such a system, but in the meantime I'll try to make the
best of what I've got to work with and make do until something better
Click to expand...
comes


Are you thinking of something like checked exceptions in Java?
I hated them. They lead to code that is cluttered with try/catch. The
problem is that if the thrown Exceptions are part of the interface for
example "Stream" you do not only have to catch Exceptions in a "FileStream"
but also in a MemoryStream or a ConsoleInputStream which is very annoying in
Java. The problem is that different implementations of an interface will
throw different Exceptions.

In my opinion, there should be a way to specify Exceptions that are thrown
by methods (throws clause), but you should not be forced to catch them.

If you compile with a special compiler parameter, the compiler will force
you to specify every Exception that might be thrown by a method. This leads
to cleaner and more robust code because the programmer of a method has to
think about what exception his methods can throw. At the moment, nobody
knows, what Exceptions a method can throw, even the programmer might not be
aware of all of them.
 
Back
Top