Exceptions (Was RE: [ANN] Cleaned up KomHttpServer on SM)

Stefano Turri stefanoturri at interfree.it
Mon Nov 8 22:46:49 UTC 2004


I'll add a cople of comment on exceptions from a different point of view,  
since
i've had a pre extensive experience in java language development and only  
recent
interest in Squeak and Smalltalk language.

On Mon, 8 Nov 2004 11:38:28 +0200, <goran.krampe at bluefish.se> wrote:

> You are indeed forced if the API you are using throws exceptions - and
> they generally do. :)
> You need to either catch them or declare that you too throw them.
>

This is true for checked Exceptions , the default behaviour provided by  
Java for Exception subclasses.
If an exception is a subclass of RuntimeException there is no need to  
declare it in
the method signature, nor to catch it in calling methods.
Not that it's not there ;-), so someplace higher in the call stack some  
methods must catch it,
without the added benefit(?!) of compile time checks.

> I am not saying it is a "fault" (when I wrote "That is very, very bad" I
> meant that empty try-catches are bad) of the language - I am simply

Agreed, except in special situation  ...

> pointing out the effect it has. I haven't thought it through enough to
> form an opinion on how *I* would like it to work in Java. I think though
> that I would prefer it to work like in Smalltalk - but perhaps technical
> details would prevent that.

I find that exceptions in method signature are very useful in documenting  
APIs interfaces.
These declarations work best for documenting external published  
(standardized) interfaces (perhaps with
multiple implementation, something like a JDBC driver for example). This  
is very
important a compiled library is provided with only documentation, unlike a  
Squeak system
with fully browseable source code.

In application logic a useful pattern is to catch exception in a method  
and wrapping them in
runtime exception (or in more general Business exception) to avoid an  
unmanageable
proliferation of throws clauses and catch blocks.
The wrapper exception may mantain a reference to its cause to allow  
further analysis/logging.

The only problem with the Java language is that by DEFAULT the exception  
is NOT a RuntimeException,
so many programmers feel compelled to always use checked exceptions for  
improving code quality
through static compile checks (Often forgetting to implement any  
meaningful form of unit testing :( ).

The main technical difference i've found between Smalltalk and Java  
exceptions is that Java
ones don't carry a full resumeable stack, but only a call stack log use  
for logging.


Stefano

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/




More information about the Squeak-dev mailing list