Java/Exceptions - Revision history

Admin: /* Good Advice */

2017-06-21T14:19:56Z

Good Advice

← Older revision		Revision as of 14:19, 21 June 2017
Line 85:		Line 85:

	Exceptions are examples of where implementation details can leak into the API		Exceptions are examples of where implementation details can leak into the API
	* SQLException		* If you have a phone number application, and it throws a SQLException, and now another client wants to implement that code on top of their own proprietary data store and not a SQL store, how do you deal with that?
			* Solution? Don't mix implementation details with program details.
	* Implements Serializable - entire implementation has just leaked out - serial form now makes ALL of your data, incl private fields, part of public serialized form.		* Implements Serializable - entire implementation has just leaked out - serial form now makes ALL of your data, incl private fields, part of public serialized form.
	* Solution? Don't say "implements Serializable". Be more careful.		* Solution? Don't say "implements Serializable". Be more careful.

Admin: /* Refs */

2017-06-21T14:18:45Z

Refs

← Older revision		Revision as of 14:18, 21 June 2017
Line 77:		Line 77:

	</pre>		</pre>

			=Good Advice=

			How to design good APIs and why it matters: https://www.youtube.com/watch?v=aAb7hSCtvGw

			Implementation should not impact API

			Exceptions are examples of where implementation details can leak into the API
			* SQLException
			* Implements Serializable - entire implementation has just leaked out - serial form now makes ALL of your data, incl private fields, part of public serialized form.
			* Solution? Don't say "implements Serializable". Be more careful.

	=Refs=		=Refs=

	http://www.javamex.com/tutorials/exceptions/exceptions_unchecked.shtml		http://www.javamex.com/tutorials/exceptions/exceptions_unchecked.shtml


	=Flags=		=Flags=

Admin: /* Custom Exceptions */

2017-06-03T07:35:30Z

Custom Exceptions

← Older revision		Revision as of 07:35, 3 June 2017
Line 65:		Line 65:
	===Custom Exceptions===		===Custom Exceptions===

			<pre>
			/** Empty exception (for stacks) */
			class Empty extends Exception {
			// Note, subclass does not inherit any constructor.
			// We can define our constructor and call the super constructor,
			// or we can define no constructor, and always use the default constructor.
			public Empty(String msg) {
			super(msg);
			}
			}

			</pre>

	=Refs=		=Refs=

Admin: /* common caught exceptions */

2017-06-03T07:35:06Z

common caught exceptions

← Older revision		Revision as of 07:35, 3 June 2017
Line 10:		Line 10:

	When an unhandled exception occurs, the program terminates up the call stack -		When an unhandled exception occurs, the program terminates up the call stack -

	~~===common caught exceptions===~~



	==Illustrating the stack==		==Illustrating the stack==

Admin: /* Flags */

2017-06-01T05:36:27Z

Flags

← Older revision		Revision as of 05:36, 1 June 2017
Line 20:		Line 20:

	The optimal way to run and inspect a program is to run a process, stop it with a debugger insertion call, attach gdb or some other debugger, and continue the process under the control of the debugger, which allows you to explore the process in real time. Alternatively, you can "manage" the execution of the program from some other kind of automated hypervisor, not just a debugger, to make instrumentation of programs much more flexible.		The optimal way to run and inspect a program is to run a process, stop it with a debugger insertion call, attach gdb or some other debugger, and continue the process under the control of the debugger, which allows you to explore the process in real time. Alternatively, you can "manage" the execution of the program from some other kind of automated hypervisor, not just a debugger, to make instrumentation of programs much more flexible.

			=Handling Exceptions=

			==Common Java Exceptions==

			First, if you want to compile your own list of Java exceptions, each package in the Java standard API will list a package summary on its package summary page. This has an "Exceptions summary" at the bottom that gives a brief summary of all the exceptions defined in a Java package.

			For java.io.* the page is here: http://docs.oracle.com/javase/7/docs/api/java/io/package-summary.html

			That being said, here are the most common:

			Method parameters:
			* IllegalArgumentException

			Arrays:
			* ArrayIndexOutOfBoundsException
			* NullPointerException

			Collections:
			* NullPointerException
			* ClassCastException (if not using diamond notation <>)

			Type casting:
			* ClassCastException

			File IO (java.io package):
			* IOException
			* FileNotFoundException
			* EOFException
			* ParseException

			Everybody:
			* NullPointerException

			Serialization:
			* java.io.ObjectStreamException

			Threads:
			* InterruptedException
			* SecurityException
			* IllegalThreadStateException

			===Unchecked Exceptions===

			* IllegalArgumentException (UNCHECKED)


			===Custom Exceptions===


			=Refs=

			http://www.javamex.com/tutorials/exceptions/exceptions_unchecked.shtml


	=Flags=		=Flags=

Admin: /* basics */

2017-06-01T05:23:46Z

basics

← Older revision		Revision as of 05:23, 1 June 2017
Line 1:		Line 1:
	=~~basics~~=		=Basics=

	==~~caught~~ vs uncaught==		==Caught vs uncaught exceptions==

	The main difference in exceptions is caught versus uncaught exceptions.		The main difference in exceptions is caught versus uncaught exceptions.
Line 10:		Line 10:

	When an unhandled exception occurs, the program terminates up the call stack -		When an unhandled exception occurs, the program terminates up the call stack -

			===common caught exceptions===



	==Illustrating the stack==		==Illustrating the stack==

Admin at 05:21, 1 June 2017

2017-06-01T05:21:46Z

← Older revision		Revision as of 05:21, 1 June 2017
Line 16:		Line 16:

	The optimal way to run and inspect a program is to run a process, stop it with a debugger insertion call, attach gdb or some other debugger, and continue the process under the control of the debugger, which allows you to explore the process in real time. Alternatively, you can "manage" the execution of the program from some other kind of automated hypervisor, not just a debugger, to make instrumentation of programs much more flexible.		The optimal way to run and inspect a program is to run a process, stop it with a debugger insertion call, attach gdb or some other debugger, and continue the process under the control of the debugger, which allows you to explore the process in real time. Alternatively, you can "manage" the execution of the program from some other kind of automated hypervisor, not just a debugger, to make instrumentation of programs much more flexible.

			=Flags=


			[[Category:Java]]
			[[Category:Exceptions]]

			{{CSFlag}}

Admin: Created page with "=basics= ==caught vs uncaught== The main difference in exceptions is caught versus uncaught exceptions. http://docs.oracle.com/javase/8/docs/api/java/lang/IllegalArgumentE..."

2017-06-01T05:21:27Z

Created page with "=basics= ==caught vs uncaught== The main difference in exceptions is caught versus uncaught exceptions. http://docs.oracle.com/javase/8/docs/api/java/lang/IllegalArgumentE..."

New page

=basics=

==caught vs uncaught==

The main difference in exceptions is caught versus uncaught exceptions.

http://docs.oracle.com/javase/8/docs/api/java/lang/IllegalArgumentException.html

https://stackoverflow.com/questions/22952140/about-throwing-illegalargumentexception

When an unhandled exception occurs, the program terminates up the call stack -

==Illustrating the stack==

The Python debugger [[Pdb]] shows a better way of "inspecting"/instrumenting the stack easily, and is much more natural to do in an interpreted language. But many of the same concepts hold true in debugging a compiled language. Although things... get weird fast.

The optimal way to run and inspect a program is to run a process, stop it with a debugger insertion call, attach gdb or some other debugger, and continue the process under the control of the debugger, which allows you to explore the process in real time. Alternatively, you can "manage" the execution of the program from some other kind of automated hypervisor, not just a debugger, to make instrumentation of programs much more flexible.