Exception topics and typical exceptions

Exception topics

I'm still waiting for the UITopics stuff to be approved by java.net. I cannot upload .jar files to my blog now (some sort of weird filtering or something), so there's nothing I can do but wait :-(

I'm still shifting paradigm between the Observer pattern (used by Swing for event listeners) and the publish-subscribe paradigm that UITopics promotes. I'm still finding new idioms and new features.

Take for instance exception handling in GUIs. Imagine I have a Topic called "application/errors". Now, whenever I have an exception, I post an ExceptionEvent to that topic. Like this:


...
  TopicManager tm = getTopicManagerFromSomewhere();
  try
  {
    doWhatever();
  }
  catch( Exception e )
  {
    tm.postEvent( "application/errors", new ExceptionEvent(e) );
  }
...
where an ExceptionEvent is a custom event...

public class ExceptionEvent extends java.util.EventObject
{
  public ExceptionEvent( Exception source )
  {
    super( source );
  }
  public Exception getException()
  {
    return (Exception) source;
  }
}
This is, I just send the event to the "application/errors" for whoever listeners may be there.

One topic listener just (asynchronously? yes, why not...) logs the stack trace...


  @TopicListener( topicName="application/errors", isAsynchronous=true )
  public void logException( ExceptionEvent ee )
  {
    System.out.println( ee.getException().printStackTrace() );
  }
While another, in the Swing thread, shows a message dialog:

  @TopicListener( topicName="application/errors" )
  public void handleExceptionWithPopup( ExceptionEvent ee )
  {
    JOptionPane.showMessageDialog( 
      ... ee.getException().getMessage() ... 
    );
  }
This is somewhat powerful. I can attach (or deattach) any of the listeners. I may have a listener for debugging purposes that prints out all exceptions. I may even have a listener that logs all events into a topic and replays them later on (to emulate user input).

Yes, definitely shifting paradigms is interesting.

Typical exceptions

On other news, I received my september copy of "Communications of the ACM" today. I just opened it and I could read:

Can you spot the security flaw?

  Try {
    Byte [] text = AccessPlaintextData();
    Byte [] password = GetPassword();
    ...
    EncryptData( text, password );
    ...
  } Catch() {
    // exception code
  }
  
"This pseudo-code reflects a somewhat common flaw ... in .. M$$soft Internet Information Server 4.0 ..."
Now, remember that article at artima about checked exceptions in C#? In the article Anders Hejlsberg said "I see two big issues with checked exceptions: scalability and versionability."

Now, my conclussion after reading that article at Artima and the ad at magazine is: in C# there're no checked exceptions because of lack of scalability and versionability at the cost of lack of security (!?).

Well, it seems that after all James Gosling was right when saying:

- What does "solid" mean?
- James Gosling: Solid means you can run the software day in and day out. When the usual crazy things happen, the software survives.

Now, I'm glad I have checked exceptions in Java!
Happy Swinging,
Antonio

Comentarios:

Enviar un comentario:
Los comentarios han sido deshabilitados.
About

swinger

Search

Archives
« abril 2014
lunmarmiéjueviesábdom
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Hoy